#9 - Building Front End Infrastructures with Majd Murad

About the guest

Majd Murad, Senior Frontend Developer at HelloFresh

Majd is a senior level Frontend Developer who also has experience building front end infrastructures. Majd has a diverse creative background that has seemingly spurred on his curiosity and passion to build great products and the environments that lead to great products.

Checkout careers at HelloFresh.

Notes

Even though infrastructure problems are different from the front end, they are still relevant and important to solve, in some cases, it's even more fun because the impact can be much greater. Creating and maintaining consistency through constraints in order to provide a better experience for end-users. Or improving productivity for developers through consistent tools and standards.

These are hard problems to solve because they involve a lot of coordination and alignment between multiple teams and leadership. Oftentimes, infrastructure efforts require an upfront investment, so the leadership has to share the vision and see the value.

There are different ways to solve the infrastructure needs. For example, the inner source model, centralized monorepo, shared components, and others. And even when a solution becomes available, another challenge is the adoption.

Transcript

John 0:13

Welcome to PragmaticLead podcast, your hosts are Alex Bachuk. And John Masse. We have conversations with folks throughout the tech industry to get real world perspective on how people make things happen for their careers and businesses, check out pragmatically.com for more content, just like this.

We're here to talk about front end infrastructure, mono repos design systems. Before we get into it, lunch, tell us a little bit about yourself.

Majd 0:45

Yeah, so my name is Majd Murad. I am a senior front end developer at hellofresh right now, and my background actually comes from the theater. I am one of those boot campers. I was actually driving for Lyft in San Francisco for two years. And I had all these passengers being like, Hey, you should just learn how to code. And I was like, Alright, and I attended Dev Bootcamp, rest in peace that no longer exists. And yeah, I got a job. First off, doing some mobile app work for runbooks, which is a, like a construction industry mobile app, helping with analytics and making construction more efficient. And then I switched over moved to New York, I worked at first dibs for a while, which is where I really kind of became more front end focused and did some deep diving into more front end infrastructure work, which is what we're here to talk about, and then made another switch then to hellofresh at the beginning of this year. So you know, January 2020, right before everything went went crazy with COVID, which turned out to be great timing, because, you know, the, we became an essential service delivering food for people during COVID, which was like, you know, kind of nice. Oh, yeah,

John 1:55

we use we use hellofresh. In my home, actually quite a bit. I'm very thankful for the very detailed instructions.

Alex Bachuk 2:02

Yeah.

John 2:04

Yeah. that come with those meals?

Majd 2:06

No, because then you kind of learn along the way too. You do.

John 2:09

Yeah. And actually, we have, we have a couple of sauces and stuff that will actually still make on our own that are inspired by things we learned by by by using the hellofresh recipes.

Majd 2:19

That's the way to do it.

John 2:20

Yeah, I learned I can cook fish. Mm hmm. That was exciting. So it's been expanding my mind and in learning in the cooking realm.

Majd 2:28

And it's nice to because now you're not bringing leftovers to the office and microwaving fish and being that guy.

John 2:36

Portion control, I think is is very interesting. Because usually I'll go when we make pasta or something. I'll go for a second or third, but with hellofresh, like, portion controls there. Yeah, I've lost 30 pounds. No way I'm running. But we also subscribe to hellofresh. So I don't know, I think there's a story there.

Majd 2:55

That's amazing. We need to make you a spokes child or something.

John 2:58

I'm the next was the guy for subway. Oh,

Majd 3:01

Jared, Jared. Fresh.

Alex Bachuk 3:04

You don't want to be that guy.

Majd 3:05

You don't want to like no,

no, no, no,

John 3:08

no, no. All right, let's ixnay on the Yeah.

Majd 3:13

Sure that that one out?

John 3:17

So measure, what have you always found yourself? Like drawn to the front end like and? Or was there like, tell us about your What have you experienced in regards to engineering? You've done like some API development in front end work? Or did you find yourself attracted to one side of the stack, I suppose.

Majd 3:33

I mean, almost immediately, I kind of was was drawn towards the front facing stuff. I think, really coming from the theater background, it makes more sense, since it's more about like, what the audience sees. And, you know, my background is, is not in playwriting, although I did do some playwriting. It wasn't in just directing. Although I did that too. It was to be on stage and recognizing like, what is it that we're presenting to the audience? And how does it affect the audience? are they laughing? Are they crying? are they following the, you know, the intentions that I've put forth? And it's the same thing when you're dealing with with any kind of platform, right? It's user experience, that's all they do is like, where, what are the focus points? Are they are we guiding them through the right way. And I really feel drawn to that, because that's, you know, you're shaping the story for the user. And then I don't know, I just kind of, I just kind of started realizing that as much as I do, like product, you know, I can never find that perfect match of like the right industry. And like really being, if I'm being perfectly honest, like 100% driven by like, what the users are about relative to the product, you know, at the end, you know, I have a job and I can be only as passionate about my company as I can be. But what I really found much more interesting was the problems that other developers were facing within my company. You know, things like as you grow, you know, you'd have things split up for example, you know, in some microservices, and then how do you keep things in sync? How do you keep packages in sync? You know, oops, I just created a breaking change. I didn't realize for this other consumer, yada, yada. And I started finding that those problems were much more interesting to solve. And for me, that's, that's what led me into front end infrastructure was, why don't we have a single component that is just a modal that is what we use across. And that's actually how I got into it was modals. One of my first tasks that first dibs was update these old models from some I think it was like from bootstrap, we were using some bootstrap modal. And I said, Okay, well, what do I replace it with? And everyone was just kind of like, shoulder shrug. I don't know. I'm like, we're pretty big company that we have like a basic component library or like, I didn't even know the word that's in bootstrap. Yeah. Right. Like, they're not the only ones who own it. So like, we can make our own or, and I had created one at my last company. So I was like, why don't I just start from scratch and build something that we can reuse that we like, and that styles for us and isn't over bloated? And they're like, yeah, that's actually a good idea. So started building that. And that led to and and there's kind of coupling there with what the user experiences too. Because if users see 50 different models on on all the different pages, that's kind of a jarring experience. Why does one animate from the bottom? Why does one fade in? Why does one just pop up all of a sudden? Why are they different sizes? Why are the X is different? Why? Why are some of them able to leave? When you press escape? And others? Don't?

John 6:31

I really empathize with that as, as a designer, that consistency is important. But why is it important? What's the benefit that you see? Or? Or what's the sometimes there's a for me, there's an emotional attachment to the, to how software is behaving? I almost like cringe. Like, why why? Yeah. Why do you think that is?

Majd 6:50

I mean, I would think I'm no psychologist, and I'm definitely not trained in user and user research. But I would imagine, I mean, my hypothesis there is, you know, if you can create a consistency and and form a habit for the user, then they're more likely to notice the things you want them to notice. You know, like, you don't want them to notice that this button is different than that button, you want them to read the copy. You want them to, like, interact with the thing, right? And, and so if everything looks beautiful, and behaves beautifully, and and is excited, I mean, we all remember, like, you know, ooh, that fancy animation that we saw for the first time, like how much of Tinder success was because of the cool swiping? You know, and that's all anyone, it became, it became part of the vernacular of this swiping effect, right? Like, oh, swipe left on that, you know, like, we actually say that now in real life, and it goes beyond Tinder. And that's, that's a cool thing that they did, because they took focus and worked on it and made it consistent. Granted, that's only one one feature, like, as opposed to how are you making buttons consistent? Did they have a consistent hover feature? That kind of thing? But I mean, if you see it, once, you kind of expect, I would expect to see it consistently over and over again. And then back to your back to your question, like, why why do I think it's important, it's not just important for the users. But it's important for the developers too, because, you know, they're going to receive, you know, some specs from a designer of a button. And then every developer is going to try to start it from scratch, unless they know that there's a component library. And that's a bad opportunity for, you know, creating another variation, that's, that doesn't work as well, or that does work better than the existing ones. And why aren't we keeping it consistent? Why aren't we having those conversations about like, Well, okay, let's talk buttons. What should our buttons do? What Shouldn't they do? And how do we make it recruitable for the developers so that they don't even have to think about it and they can focus on the bigger picture?

John 8:47

Right? Do you think we sometimes over trivialize the amount of effort that goes into, like building applications? 1,000%?

Majd 8:58

Yes, I, I have the struggle a lot with product where I try to push for making things as stable as possible. And I guess it depends on the stage and the the expectations that your company has, like, if you're at a startup, yeah, you got to like, move fast. And you can't really focus on you know, over documenting everything when you're like, when a five developers that I totally recognize. At the same time, if you end those five developers sat down in a room and said, Okay, let's just quickly say like, Okay, what, like, especially for basic UI components, what is what is the button going to be, let's knock it out, let's, let's figure that out and be done with it. And now as you develop it, because you have a need to develop quickly, you have those tools, literally tools in place, and then for a bigger company, it becomes a struggle because there's so much focus on those like micro improvements, right and, and these deliverables, and we have to increase this by like, point 5% by this date, and, and it's hard to, to kind of push an advocate for yourself and say, like, you know, just raise your hand and say actually Can, can I just spend an extra week really making this as robust as possible? Because it doesn't just affect our, you know, portion of developers that work on our product? Right? Yeah, it could affect everybody. If I spent that much more time as a company, we could, we could go faster. And it's it's not only difficult to explain that it's difficult to put numbers to that, right. And that's always bigger companies, what they push for is like, prove it. Prove to me that this is the this is the most efficient, yeah, the most efficient and productive use of our time, there's a value here that we haven't discovered yet that we might not understand. Exactly, yeah. But it's part of the practice of what we rely on people to be doing every single day. And frankly, like, there's so much work that you have to put in to be able to prove numbers that then you have to, it becomes this vicious cycle of like, Well, can I then spend time building the tools to deliver the numbers to you, right, the next thing, and it's like, well, if we could wave a wand and convince the product, people in charge that like, if you could just avoid me doing all of that, and trust that I know from the code, and from my experience, that, that if I build these components, if I if I work on it in this way that things are going to be faster. And you'll see that once we start developing features using these tools that on average, things will get faster, that'll be the number to prove. But it's really difficult to convince them because it's such a big undertaking.

John 11:33

Well, then even after you convince, convince stakeholders, then that you have the challenge of measuring. It's like okay, now show me I gave you the time Now show me how it's how it's having an effect. And that's not always easy either, right? Because we're talking about people's productivity. So what do you look at pull requests are, but even those abstractions don't always tell you the reality of what's actually happening? Or how much work is going into something? Yeah,

Majd 11:57

I mean, for me, I locked out first dibs because product started well, it wasn't product act, it was the director of engineering, Rob Richard there, who noticed that I had a knack and, and passion for that, then he kind of pulled me out into a solo roll that became available for fronted infrastructure. And basically made it interesting to me by saying, like, you'll be able to work on this exclusively. And I was like, what, that's cool. Like, I don't have to worry about building out, you know, an entire feature or working on translations for it, and blah, blah, and all the other little tidbits, I can just focus on making these basic components as efficient as possible, as easy to use as possible as well documented as possible. And because it was through him, and we were a small team, like just that infrastructure team, we didn't have to prove anything to anybody. He could just, you know, delegate those tasks. And I could, I could push back or whatever, it was just the two of us, basically. And we would confer with other seniors and lead developers in the company on like, the major decisions. But for the most part, we were pretty, like, we had free rein to make the improvements that we felt were necessary without having to prove them with numbers. And we knocked it out and ended up making things so much faster for the developers, and everyone noticed.

Alex Bachuk 13:17

So not every company has an infrastructure team, right from an infrastructure team. So maybe you can tell us like what the role is of that team, just in general responsibilities and how it helps the rest of the engineering org?

Majd 13:31

Yeah, I mean, I guess it varies from company to company, I am not on the infrastructure team at hellofresh. I am on a product team, again, attempting to contribute and our front end infrastructure team is focused on right now moving things into a monolith and and I bring that up to say like the responsibilities can kind of vary based on like how they define it. I see front end infrastructure, as you know, the general support and improvements that all final like how do you support and improve the experience and development time for all front end developers? Right, while having a mind for not just the development process, but you know, the CI How do you keep in mind on the unbundle sizes, how do you keep in mind for like future technologies and how you how you transition to those things? How do you maintain the codebase, like, who is responsible when you're when you're in fragmented teams for updating, react, for example, across all of your projects, who owns that, and that feels more like a front end infrastructure person or team. That way they know how to go through and sweep through all those things. And it doesn't have to be something that you delegate to all the independent teams because that's not something you can you can update and like based off of when people are free to do it. Right. You kind of have to do it all at once. So a single team should own those kinds of those kinds of tasks.

Alex Bachuk 15:01

Yeah. And john, you are in for infrastructure team as well, right?

John 15:04

Yeah, we actually might we call it the platform or platform. So it's very similar parallel, where we're hyper focused on developer productivity. We even run groups like the developer experience. So like a committee where we have folks come in, and we listen to developers talk about the problems they're having, maybe even talk about, you know, how we're going to change systems over time to meet their needs.

Alex Bachuk 15:27

Yeah. And it was a challenge. Remember, it was a challenge to actually get this team formed, we had multiple attempts to actually prove that there's a value in this and is to form this team and fund and have resources behind it. I think we tried, like, you don't intra-source type of model where it's a shared kind of components, and everybody pitch pitches in and we maintain, we have this community, and sometimes it works. Sometimes it doesn't. How do you prove that value? I think Majd you, you were talking about the value. How do you do that?

Majd 15:58

I mean, that's the question. You know, I know that for for hellofresh. We're, we're going through those, those speed bumps right now, where design and front end sometimes aren't in sync. And design definitely has the design infrastructure, I think it's actually much easier to have infrastructure for design, relative to front end infrastructure that then matches that. Like I said, any designer can produce the button without, like, you know, regardless of how the front end actually implements it. And so let's bring it back to the, to the measure, like what we did was we created a kind of audit for the system that we had in place, we had like a beginnings of our front end infrastructure. And the best way we could measure was okay, how many times are we overwriting existing styles to recognize, you know, like, like, where the opportunities are to kind of move things and convert things into a single pattern, right? And then that becomes one metric. So it's really based off of what the problem is that you're trying to solve. The front end infrastructure is so broad, like, for example, there's we haven't even gotten to the mono repo portion of things like, how do you prove that the mana repo is the is a measurable, actionable thing to do that is going to bring value. I remember facing this problem at first dibs where I was trying to find a way to make those measurements by saying, Okay, well, right now, for example, we have these layout components. And we we basically put them into a single package that would that all of the different that all the different, we'll call them fragments have have to keep them in sync, right. And so what we did was whenever we had to change, let's say, a design system package, we would have to update it in the layout. So that's one set of pull requests. And then we would have to update it into all of the different the fragments that then use those. So we're talking about like, potentially up to eight, maybe even 15, pull requests, just to just to update packages and keep things in sync. And that process could take anywhere from like two hours to like a full day, depending on people's availability to provide feedback if necessary. Or maybe there's a blocker for some reason, because someone else has another conflict with updating that package, etc, etc. And, and in the end, it didn't make sense to sit there and try to add all these analytics tools, just to figure out how long those things were taking. We just knew that they were exorbitantly long. And then by once after we made the decision to move things to the to the monitor repo, once, once things did move into that monitor repo, we reduced that hours, maybe even a full day worth of waiting time for the developer down to like 20 minutes. Now tell me is it worth spending all that time just moving things to the monitor repo, when a full day of waiting becomes 20 minutes versus spending the time to build the tooling to determine that it took a day? You know what I mean? Like, yeah, at some point, you just got to tell the people in charge, like, Look, I could spend waste my time on proving it, or I could just do it. Right, you know, especially when it's such a drastic change.

John 19:07

Right.

Majd 19:08

But it's, but without the proof, it's hard to convince them.

Alex Bachuk 19:12

Before we get into mono repo, I want to take a step back and talk a bit more about the infrastructure team. Do you have an experience where with the model word, but the shared model with the inner source model, where the teams kind of collaborate between each other, and they build the shared components build kind of infrastructure around that without actually specialized team?

Majd 19:34

Yes and No, so the experiences that I've had so far, show that, you know, a lot of developers and product and designers are very hyper focused on their work, right. And there's never, I shouldn't say never, but there often isn't a mind for the bigger picture and how it affects other teams. Right? I see that even now at at hellofresh where sometimes people Not only are people focused on their on their features, but there's a lack of awareness of other features and parallel work. And not only is that inefficient, but that leads to a lot of duplication. And ultimately, and in just an experience, an inconsistent experience for the users in the end, right. And ultimately, we're building things for the users. And it's hard to remember that, like, we're also user, like the developers, the designers, the product, people are also users not of the final product, but of the internal tools. And so when you're siloed, like that, and you don't have a plan in place for how you share things across the board, I mean, chaos reigns, right? Like who's to say one team won't won't start shifting to have all of their stuff in material UI? Who tells them no? Right? Ah, there's the big word that I love. No. And it seems like an impossible word for some developers to say to their product owners to their, to their designers. No, I'm sorry, we have an existing thing that doesn't look like this. Let's have a conversation about why this isn't the direction or let's have a conversation what for why this should be the direction? You know, but yeah, but if you introduce something new without keeping in mind, the old. And, and and the stuff that exists, you know, again, inconsistent experiences across the board.

Alex Bachuk 21:26

Yeah, well, it in my experience, this this model never worked. We tried a couple times in the past. And until we actually formed the platform, front end infrastructure team that owned actually owned this part. It just was really confusing. Who owns which part who's going to maintain it, who's going to update it, new feature comes like what's going to happen? So teams kind of tend to just fork a component and like, we just have this priority, we have to move fast. So we don't have time to to work on this shared initiatives in quotes. Go ahead,

John 21:59

and what are their world? Do you tell your boss your stakeholder? No, right. Like, that's not, I think, I think it's actually I don't think it's a problem of the people. But how we, but maybe it's just a style of work that most of us are uncomfortable with, to me, it takes time practice, because at the end of the day, if you're, if you're in a silo, you're never really encouraged to think outside of the boundaries of concerns that you're subject to. Largely you're, you're measured on your ability to close a ticket on behalf of some requests that somebody's making for you. And then when you look at that, you're almost motivated against thinking about others. Because you're not measured about your ability to collaborate with other teams, you're measured on your ability to write a new button, and put it out on the website, for better or worse. And, and then sometimes, if I'm an engineer on a team, and I'm looking at a design system, for the first time, I say, like, Look, I can see in my mind, from right now to button in prod. But if I have to look at the design system, that's going to take me three days, before I can even start getting my markup on the on on the page. So there's, there's contention there. And that decision has to be made by every individual on every single team every single day.

Majd 23:20

Yeah, I mean, it has to come down from leadership. And and like you say, there's, there's got to be a team, or some kind of person or persons that own, you know, that part of the platform, if it's a platform team, if it's a front end infrastructure team, it doesn't matter what you call it, as long as there is some ownership. And if you're in a small team, and you don't have the resources to have to have an individual own, that, that's fine. But if you if you have that principle in place of, you know, if you are a team of five, you don't need to do that as much overhead in terms of like, oh, there's too many new components, and how do we keep them managed? Because you're just five people just turn your chair around and talk to you know, Bob, or Sally right next to you. And you can just say, like, Hey, I didn't you say you were gonna be working on on this button component? I'm gonna be working on that too. Why don't we talk about what it shouldn't? Shouldn't have? And then oh, you know, what? We don't know that question. We don't know the answer to the question of like, should the disabled state show this cursor or that cursor? Like, let's talk to the designer, and it's it is an overhead right there. Even in that small team now you're talking about having an extra meeting talking to someone else but but in the end, you're making the the code healthier, you can document the conversation in a way that like proves that you have had a conversation about this, that you know that this was an informed decision from a from a designer from a from a UX researcher from a from a product person, etc. And now you never have to worry about it again. Or if you do have to worry about it again, because someone introduces a new idea. You can point to this thing and say well, we originally decided this So prove to me why it should now be this as opposed to having nothing in place, having had the spent none of that time. And you know, a year down the line, this happened 20 times now you have 20 different iterations, right? Which is a lot more maintenance. Right?

John 25:15

So So would you say that for teams that are in the position of in for platform, etc, there's also an opportunity, and I want to be careful with the word obligation, because I think there's, I think there's a responsibility to those folks to teach others how to think broadly about their work, and to think about the effects and to actively lower the barrier of entry into the commonality of how people work, like almost feel like there's a there's a responsibility to that team to also help other people understand how to use the tools for the sake of productivity to reduce the anxiety they might have for meeting the the goals that are immediately in front of them that they're they feel like they're getting measured against

Majd 26:00

Sure. I mean, I think it actually goes back to the, to the concept of proving it, right. Like, and, and the only way to prove it to the to the people who actually are using the tools, right, the developers in the end, it's just build them and and then they can see it happen. And I say this because at first did I remember there was a lot of resistance, I remember I used to I used to review some some poor requests that continued to use old components. And I'd say, hey, there's this, use that use the one from the component library, use the one from this component library, use this changes to the end, you know, I go through and do a full sweep of this 100 line, you know, PR and it would just be like 100 comments, and people would be like a managed, you know, calm down. And I I even felt kind of kind of uneasy about giving that much feedback. But I'm like, this is the way to do it. I have to be diligent. And you know, they were begrudging. I think at first i they never said anything, but I kind of got a sense of like, because you know, you know, when you leave like 100 comments, you're like, Am I the asshole. And then they do it over time they adapt, they get used to it. So where does the responsibility lie there that was on me to kind of push for it. But then this magical thing happened, where they started realizing over time, wait, now that I've learned these components now that I've learned how to contribute to those components, it's actually a lot more fluid. I never have to recreate a button. I never have to recreate a modal. It's just there. And it works. And I don't have to question the designer about how it works or what it should do in this state. And there are no bugs, because there are tests already in place for these robust, you know, thorough components that complete the thing that you expect them to complete, right? Yeah. And it was great. I even get compliments from people doing like, we would have internal hackathons. And like, dude, I was able to complete that whole page in like an hour, because all of those pieces were there. I'm like, exactly. Right, exactly. So there you go. And now they become then they eventually became the advocates for that design system that we put in place. And they started telling the designers, No, we won't use that because this exists. And if the designers complained, and this was the key is I was connected to the head of the design department who completely encouraged and really wanted to reinforce what I was doing. And so he would try to reinforce it on his end. And in the design teams to say like, this is the process we're going to go through now like, yes, if a developer tells you No, because of the design system that they have in place, we you need to bring it back to us, and we need to talk about it. So do we introduce this color? Do we introduce this icon? Like because this other one that's similar already exists? Maybe we should just update that, like, we need to have that conversation. So things don't get, you know, explode exponentially as time goes on. It's just not a scalable solution to keep it siloed. Like that.

Alex Bachuk 28:55

I can imagine there's going to be some challenges with when you have this team, right? It's a centralized team that has a lot of say and how things are done. So almost becomes the gatekeeper. And the company. Yeah. So what are the challenges if working in this team interacted with engineers, product managers, designers, executives,

Majd 29:17

the biggest one that I faced, I think well initially was was, as I mentioned, the the developers kind of being reluctant to use the system in the beginning, followed by then I got a sense from the designers, some of the designers that it really restricted creativity. Right. Now you have the question of like, well, if we always have these buttons, there can never be new buttons like we've restricted our design system so much that you can never create something original and new. And and that was never the intention. In the beginning. We had to restrict, right we had to say like, I know there's 100 and I know you want to keep going, but let's bring it down to 10 and figure out why how and when we introduced the new patterns. And it's hard to convince designers that because they want to create their their creative, I'm a creative, I totally get it. My sister is a creative director and she likes to push boundaries to sheet she tries to create new stuff all the time. And when they come back and say like, this is not the pattern, this is not that, you know, it's frustrating. And it's hard to prove again that over time, those will loosen those reins and create better tools to have you contribute. I'll share the opposite experience, which is now at at hellofresh. Our design system is completely tokenized. And, and very loose in terms of the design system library. In fact, I would call it less of a design system as much as it is like, because it is designed tokens. It's like the beginnings of the design system, right? In the end, you do want a single drop down that has state that has all of these pieces to put together rather than here's the token for the color, here's a token for what the input should look like. Because now you have to combine them together into behavior. And it was set up that way. Because they didn't want to say no to designers. They didn't want to say the product people who wanted to try this in this other in this other way. So there's always conflict there. And again, it comes back to saying no, it comes back to saying like, how can we restrict this first, and then make the improvements later, and stretch and branch out later? It's a difficult conversation. And it's a really depends on how flexible the team can be in terms of, you know, accepting the know and saying, Okay, well, we'll just not do that now. And we'll like, our designers will just stick to the pattern that is there now until we get things stabilized. And then let's have a meeting in a month, or let's have a meeting in six months, whatever it is, whatever it takes to get it stabilized. In the end, it comes down to feeling sometimes that front end is, is just labor, as opposed to the end product, which is the end product is ultimately what the user sees. It's not the design, the design can be beautiful and dynamic and, and have brand new, beautiful animations. But that's not what we're going to code. Right? And if and if our code is unstable, that instability will be evident to the user.

Alex Bachuk 32:25

What about you, john, any challenges you found working on an infrastructure team?

John 32:30

I mean, I can definitely empathize for a lot. I mean, okay, so we're changing how people work, and a lot of ways. And that can make people very uncomfortable, largely from an objective point of view. So I have to, I know, I'm signing up to build or deliver this suite of features for this for this next increment. But you want me to do it this way, or you want to move my project into a mono repo like, or I have to contend with mono repo tooling, or you're changing things about tooling. So I find that where a lot of times, like introducing new ways of working for folks that go against their immediate practice are how they practice today, the conversations, it's tricky, because when you're spending so much time thinking deeply about productivity, and trying to make a difference for for folks. And you get that pushback or you get like complaints or pockets of areas of you really want to get the feedback from whether you're not getting it, just managing the emotional effect that has on your team who's spending a lot of time on this on these efforts. And to know that these are good moments, and that we should pull those people closer to us. Because they're saying something, they have something to say then we want to hear it, then we want to bring it into our work and we can improve it. So from a culture perspective, it's, it's pretty tough. I'd also say, your environment and who's actively working in the moment. Because if you've been with a company for a long period of time, leadership mindset changes. So some managers might say, might prioritize themselves and their thinking over the broader hole. And once you have a strategic leader in that position, it's very, very hard to get an honest commitment, you might have like a verbal one. But under the covers, they're not actually using those things. And there's these fragments appearing. So as you know, someone in my position, and I'm looking for saturation of adoption, then those stories can actually be harder than actually doing the work. Because what I find is the technology part of it is not usually the problem. We there's a lot of good options out there. There's a lot of good practices, nowadays great blog posts, great influencers, great open source projects, but when it comes down to the people in the implementation, it's sometimes hard to get that buy in. And then even you get criticized sometimes like mono repo mono repo, there's, you have it's polarizing. You have some folks that are just very Like, yes, mono repo is a no brainer. And then there's an entire I think there's probably maybe a majority think that Polly repo is safer. And maybe it is. But that that can lock a company in not making a decision. And that's why I think having a team is good because then at least you have, or at least an architect someone who's accountable for the for the decision, because then you can make a decision and say, let's let's move forward, or let's divide, devise some places where we can create escape hatches to get out of the decisions we're making. Because if we're not sure, if we're not sure, going into it, if it's going to be good for the broader order, hold the org. So change and influence, I'd say are very difficult. And it can really, like measured, it sounds like you had also some strategic leaders that were partnering with you to make sure that the right conversations were happening within their organization. I bet, if you didn't have those relationships, it would be even harder or even take even longer to achieve some of the goals that you were trying to achieve,

Majd 36:06

oh, it would have completely failed. Actually, when they offered me to switch to the front end infrastructure role. I was so frustrated with the lack of support up until that moment that I was about to start looking for a new job. Yeah, because I felt like everyone here wants to be stagnant. Everyone here, and this is the blessing of the end and the curse of something that I actually got from Dev Bootcamp, which, you know, that Bootcamp, I loved it so much. They, they focused a lot on engineering, empathy, and emotional intelligence more than they even did the code. And one of the biggest and best lessons that I learned and it reinforced something that I already had in me was the concept of fixed versus growth mindset. Yeah. And how do you teach that in the culture of an of an engineering organization? That's like the crux of it all. Because if you can convince everyone to have a growth mindset, then all of this stuff becomes a little more fluid and a little more able to, like, make these changes to try new things to to have people adapt. One of the biggest problems you mentioned, too, is, is how do you get the developers to adapt? Or how do you get the people to adapt to this new system or to a new way of doing things? And that stagnancy comes from a lot of times for fixed mindset? I know my way is working, and I know my way, and it's fast for me, why would I want to change it? Why would I want to try it new? My response to that is always like, you know, you didn't come out of the womb using this. Like, you had to learn it at some point. And you had to learn that this was the fastest thing for you. So at some point, you tried the next thing, you know, you didn't only only have you know, milk from the bottle, eventually you tried a hamburger and you thought, Well, that was better.

John 37:57

Hamburgers are way better.

Majd 37:58

Hamburgers are way better. But if you didn't want to try it, just because that milk was so amazing, and you couldn't even imagine anything out there being that much better. At some point, you just got to say, Well, you know what, I'm gonna try the hamburger. And in this case, it is. Yeah. Why don't you try the new way of having a design system? Why don't you try a mono repo? Why don't you try these things?

Alex Bachuk 38:20

Yeah, but it's also incentives. I think we talked about incentives and what's rewarded in the company and the organization, even, maybe 95% of engineers would be open and want to try new things. It's just not incentivize, you just have to keep meeting your KPIs and goals, and it's a new mono repo infrastructure setup will just not you will not get you there. And if you're going to start saying no, a lot of people will be pissed. Yeah.

Majd 38:47

But that's to your point is exactly why it needs to come from the top, it really comes down to the leadership, acknowledging and and choosing, you know, that growth mindset choosing to to want to move in those directions. Hopefully, not often, but sometimes at the cost of delivering parts of the product, you know, yeah. Because Because it's future proofing, or it's future thinking. But it's hard to it's impossible without that leadership support. Right, right.

Alex Bachuk 39:18

But But leadership needs to understand there is a value, right? So you probably need to show some some value immediately. There's some something that we can we there's a return on investment, right immediately. And then it's a long term investment, and they have to buy in into that and you have to deliver on those promises.

Majd 39:35

And we bring it back to proving right, we bring it back to now I need the time to build the tools to proving the thing. Whereas if we could just have leadership who recognizes this, you know, and someone comes like if I as a senior developer, not a lead not a chapter leader or a staff engineer, whatever, go to, you know, a CTO and say, like, let's say I'm at a smaller company, and that's what it That's who I talked to, and say, like, Hey, I really think that we should move things to a mono repo that they don't go, Oh, that's ridiculous. We don't have the time and resources for that. And what we're doing right now works, like, eek, you know, like, I would never want to work at that company where where that leader is so immediate to shut it down, because that's just the way things are, right? I mean, we're in tech, and tech is gonna evolve with or without us, you know, it's, there's always going to be innovators. So how do you stay on track with those things? I would argue like even going back to the mono repo thing that by having the mono repo one of the biggest benefits is you make one improvement, you make it everywhere at once. And now you don't have to worry about when you're siloed, when you have a bunch of different repos that have to be updated that things could take a year to up. I mean, literally, that's what I, when I started at hellofresh, tried to put in one single es lint configuration for all because I was like, oh, we're kind of all over the place in terms of our code style, like, Can we just have a single and then people agreed it was a good idea. It is still not done. It has been a year. Now we have like 25 front end repos. I mean, it's like, it's, and it's impossible to get the other teams to implement it. So I've had to, like do it myself, you know, and I'm not an infrastructure person. So I'm having to take time away from my product team to be able to do this, because leadership didn't think it was a priority, right? And that's super frustrating. I do want to get that done. By the end of the year, I've got like five left, so I think I'll be able to make it.

John 41:33

But when when we say top down, I wonder if it's we're not asking permission to do this one thing. What I think it is, though, instead is that our leadership team is open to the idea to allow us to be curious, and to make maybe a few more mistakes, and to spend our time a little bit differently to make decisions that might help us be more productive for the long term. Does that you know what I mean? Like, it's, it's inviting, why I think that's so important, is because if it's a project you're worried about, and not a culture paradigm, where everyone is invited to be curious about their work to be a little bit more pragmatic every day, and to say it's okay to say no, we encourage that if your leaders are behaving and acting that way, or saying like, you know, or audibly investing in things to or the people to make decisions to help them out. I think more conversations like this and more projects like these, like a mono repo could emerge. And a conversation I wonder if a conversation between teams is instead of opposition because we're, we're fighting over whose work is going to get done first. Instead, we're saying like, well, how can we learn from this, and where the place that we can start we go on this together knowing that we might learn something that pushes us away from this idea because that should also be okay, is the metric shouldn't just be I'm going to work on a mono repo, I'm gonna build a mono repo in the world is going to be dandy. That's, that could actually be wrong. We could do it wrong. mono repo can be tricky. There's a responsibility there.

Majd 43:09

There's always cons.

John 43:10

Yeah, absolutely. And some systems, some teams might not be able to get it right for them to meet their needs. And that's, I think that should also be okay. If your leaders are saying that, hey, look, we tried this thing, we celebrate the learning, right? We understand what we tried, maybe we'll try again later. That'll be up to us as a company at that time. But in the meantime, let's take what we've learned and move on from it, and and go on to the next thing.

Alex Bachuk 43:34

So what is this model repo? Can we get everyone on the same page, what the one repo is and maybe talk about pros and cons, and then we can talk about some challenges after so what is mono repo?

Majd 43:46

So once upon a time, we had monoliths, everything is in one single codebase. And as a company grows, they find that Oh, no, our build times are now like an hour or two hours, or, you know, we need a and now we have a hotfix that we need to do. And the hotfix takes takes an hour to get out. And that means we've lost now $100,000 because no one could check out, you know, so Okay, well, we need to we need to find a way to make this faster. It's always about making it faster, simplifying the process. So people decided was let's split them all up into microservices into fragments, whatever you want to call them. Everything is now in a different repository. And this way, this team's work doesn't have to conflict with that team's work and whether or not you do you do you know release to like rapid release? You're not on like a release cycle. It's just, you know, what's there's a term where I'm a

Alex Bachuk 44:47

genius deployment,

Majd 44:48

continuous deployment. Thank you. I was like, wow, where's the word? We've been doing it? We only do that at hellofresh. So I saw I don't even call it that because that's just what it is. There's no like, other thing. So yes, now We're in that Polly repo methodology and everyone is independent except Oh shoot, now we have, everything's kind of out of sync. Everything's kind of like it's like a tree. And now the tree has fruited. And now we have this forest. And each different tree is growing slightly differently. And, and when one person walks from one tree to another, they go, Wait, I don't understand how to climb this one, because the other one looked like this. And now we have to spend all this extra time figuring out why they're different and how they're different. So mono repo is an attempt to bring all that together, distinctly different from a monolith in that a mono repo, from my understanding, and my usage of it is, is how do we keep things together? But separate? How do you still How are you still able to deploy just a chunk of this thing, without having it affect all the other pieces while at the same time benefiting from having everything in one code base, depending and, and using the same tools from one code base so that there is no overhead for, you know, making a package that you have to update? Now, in 50, places, you just actually make the change in one place. And it affects the entire codebase at once, for better or for worse. And there are tools in place for that some people use learner, but that's still for packages. And we actually get first dibs. We started with learning and then eventually moved everything to from one mono repo, which used learner to another mono repo that didn't use it at all, and was strictly using yarn workspaces and deployed directly from there. So there was no need for us to build packages outside of that repo, all the packages, all of the design system, all of the libraries and components, shared components, all of the deployables everything in one place.

Alex Bachuk 46:49

I said, john, I know your guy's using a different set of tools.

John 46:53

Yeah, there's actually a number of them now, I think, nx from norwall, which was the folks that built Angular, have you heard of that? One? No. And then the other. There's a couple others that we use, we use rush from Microsoft, which under the covers use pn uses pmpm. But we did yeah, learn a, what was tricky about we use learner for our design system. And yarn workspaces was also very advantageous. But we wanted a bit more tooling, like, what's interesting, what was cool about NSX was that they added things like telemetry, so they could let you know, like, what things affected what, and graph that out for you. But the problem we had was that we we needed as part of the adoption strategy, we thought it was important to allow people to have different versions of common dependencies for a period of time. And then we gradually allowed, like, work on homogenization of those things to get more common adoption, but not all at once. So Russia gave us a lot of flexibility, there is a compute trade off that you make, because if you have X amount of versions of one thing, it'll create another branch on your tree. And then it just exasperates the or prolongs the amount of time it takes to resolve those things. But it's been, it's been a really good tool. And what I'm what I'm really interested in too, is understanding like getting more feedback, and how engineers are practicing. So now we're starting to look at onboarding telemetry or many agents that live with the programmer as they're engaging with the tooling in the mono repo so that we can get a sense of what they're getting hung up on, or are there any processes that are taking a special amount of time, it also uses pn p NPM. are performing NPM. And it just has a very different model for how it resolves common dependencies. So it uses symlinking. So it could say, like, oh, I'll look at all your package files. And I'm installed the things you need every word just one time. And I'll symlink those down into your into your application for you had a an can also build off of a cache. So you have like this incremental adoption for things or as new dependencies are introduced, only those things are being changed. So it's those are some of the things that we're looking at. But yeah, we use we're using those tools. But there's no, I don't think there's any wrong way. I think it really depends on each case by case what you're working on. I think yarn workspaces are great, actually, pmpm just I think they they have their own flavor of workspaces that they're, they've put out and we're we're actively looking to get into that right now.

Alex Bachuk 49:28

So what are the biggest difference between monolith and mono repo? Because sounds like we went from monolith one application one code base to multiple code bases back to centralized codebase.

John 49:39

That's a very important question.

Majd 49:42

Yeah, I mean, if we're talking like, if it could be black and white, that would be my distinction would be would be a mono repo has small pieces to to deploy rather than a monolith, you'd have to deploy all at once. That could be one definition. I know I'm sure others have have different ones. That's how I use them. There's a lot of gray area in between, like, even with our new infrastructure, now we're developing at hellofresh. They're calling it a mono repo sometimes and a monolith other times. And the concept behind it is to is to go back towards having to really making it a single page application. And for all of the various benefits of that, that that has. But that's tricky, right? Because if you have an SBA, how do you how do you still do micro deployments, and again, I'm not on that team now. So I'm not as familiar with the ins and outs and what and what, what the efficiencies are there. So and I can only speak to my experience, there's only so much reading about it, you can do without actually using it to really understand the the ins and outs. And this is this is sort of the problem with some of these bigger infrastructure problems is you can't just do a quick YouTube tutorial and try it out in a small codebase. You either like fully commit to the thing based off of some, you know, information that you that you can dig up on it, or you don't. And that's it.

John 51:09

Well, the distinction for me the distinction between a mono or like the mono repo monolith, I don't think are the same thing. Like when I hear monolith I hear like more tightly coupled pneus between code components. For instance, if I have two, let's call them react components. But you can't have one without the other that smells like monolithic behavior. But in a mono repo is a very, I think, a very different science because a mono repo says that I'm going to allow for all of your projects to coexist in this space. And I'm going to give you the tools to create boundaries between how those things are managed. Now, you could create a monolith out of two components within that same ecosystem. But that's a decision that's a programming decision, where the roles and responsibilities of the mono repo is to provide tools to help people understand where their boundaries are. And that For instance, if I put a pull request in, and I need a code review done, that the right teams are engaged in that conversation. And then the deployment pipeline, you know, the tools that the continuous integration understands the tooling embedded in the repo in a way that optimizes the pipeline, component tree and that kind of work. But you can have a monolith within a mono repo. Sure. But the mono repo tools should help you understand those things that depend on each other, so that you can create safe releases without having to manually orchestrate those things in sequence or series. So I'm sure we've all experienced that before. Like, oh, you can't turn this on yet until this is enabled. Those are the characteristics of a monolith because the stacking order is significant.

Alex Bachuk 52:49

And there's probably different levels, or kinds of mono repos, like there is a Google scale mono repo with tools like basil, right with everything in it back end, front end services, API's, everything you can imagine. And there are more of a specialized mono repos like this is just a client side front end code, only JavaScript that can be managed with learner, and there's no room for back end for Java services. So there's a great,

John 53:15

there's a scoping area to like some companies that can afford it. Like if you're like Google scale, then you have scientists, you have PhDs, you have people available to spend time managing that complexity. For teams like that I've worked on and measured, I'd like to hear your thought on it, too, is that we have to control that complexity. We can afford to invest in specialized technology so much that we can say, Oh, you can draw this. But I think Google has like dynamic scoping in a way where you can say, give me this code, it's version and then when you reintroduce it into the ecosystem. There's a lot of smart science that's happening on checks and balances to make sure the right resolution is happening. When if you're using Lorna, that's like a little baby scope in comparison to that, right. So Google science is everything is in this repo, where most of the companies that I've worked with, it's like we're actually going to just manage this portion of our, of our software with with this model, maybe we have two repos, two mono repos, for instance. Yeah, I

Majd 54:22

mean, just to just to give some sense of scale, right? At first dibs, it was me. And then sometimes my director working on moving things to the mono repo. Also, there was another assistant director del tan, who would who would help out. And between that work, we were barely able to get it all done after about a year, year and a half. I mean, imagine that, and the front end developers, I don't remember what the exact count, I want to say it was about 25 front end developers. So think about the percentage of time and effort for just us to be able to do just that piece. And we're not even talking about getting into those bigger technologies, right. And then Now at at hellofresh. Also for scale, two of the top, you know, there's a staff engineer in a chapter lead and there, and they own a lot. And they've basically been working on this new infrastructure monolith project for the better portion of this year, and to the detriment of anything else that they own, you know, like, they don't have the capacity, almost impossible to get a meeting with them to get consultations on things. So it's like, you know, it's a lot of overhead to even do some of this work. So there are challenges to using some of these technologies. Again, how do you prove that that's worth it? And how far do you go?

John 55:40

Right? Yeah.

Alex Bachuk 55:41

How do you identify a good candidate for monetary but like, at which point you say, oh, mana repo makes sense, in this case, for this setup for these set of challenges that we have? So where's that fit? Well, I

Majd 55:53

mean, I think it depends on it depends on dependencies, right? With front end, it's all libraries and dependencies and, and keeping things in sync. Really, right. It's one thing again, if you have like 50 different buttons, and then if one day you make the decision to have one button, how do you keep them in sync across all of the spaces? And not only that, you know, you have build processes, right? Like, why do do we then need to have like 50 different variations of our of our, you know, continuous integration processes, just so we can make it fine tuned for each like, and how much maintenance is that? And how much cost? Is that right to have all those different instances and whatever services that you're using for that, which, you know, you're not building those things yourself, you're using third party tools, and those cost money. And not only do those cost money, now you're spending your money on maintaining your version of that 50 times or 20 times or five times when it could just be one, right? So looking at those pieces as a whole? What are those things that if we were to move into one, versus if we were to stay in five or 10? Or 20? Like what are the what are the actual costs in terms of money? Like ultimately, that's going to be a good number to prove things to prove stakeholders, right? So that costs should be greater than cost of putting together and funding the the front end infrastructure team? Exactly. If you let this developer who earns this much in one year, spend all of their time and energy on on this project, in five years, you will more than make up for that money, right, assuming that this technology stays relevant for five years, and we don't magically get some new tooling that we have to move towards as well. I mean, things move fast, but they also don't, you know, like, React has taken over from jQuery. But how long did that take? And how long will it last? Right? Things like that. So do we end up moving towards different different libraries, different technologies, different ways of putting together our codebase, you never really know you can do some research and, and get the best estimated guess. But that's part of your conversation and research and proving it to the stakeholders, right.

Alex Bachuk 58:04

But there's also got to be a cost of, like you said, they're different, almost like architectures in these 25 repos, or how many repos you guys have, because they all use different types of types of buttons and models, right? So the architecture got to be different to move them into mono repo, you have to standardize that architecture somehow. And that there's a cost for that. So the team's products have to either stop or delay their feature development to get into this centralized architecture.

Majd 58:36

We'll see. That's why it took first dibs, as as long as it did was, I loved our approach for how we migrated things. First, we made sure everything was consistent in the scripting for for all those all the CI This is the shared Webpack. This is the shared lint configuration. This is the shared testing configuration, like all of those things, we set up in packages, adopted them in each individual place. And so that way, there's like a slow migration towards this convergence of like, you know, normalcy, normalizing all of these different pieces that are going to be the same when we moved to the mono repo. And even if we never did move to the mono repo, having a single scripts package was already a huge improvement, right? The only problem then becomes keeping it in sync. And there are ways to automate that like you publish this package, and it automatically creates pull requests and automatically merges them if nothing happens. But again, that requires effort and tooling when you could just at that point, put them into the same codebase. Right, especially if you're having to wait that whole process over and over again. If you do that 100 times a year. It's probably more than that. Let's be realistic. Absolutely. Then then spending that time instead of wait instead of the time you would spend waiting spending that time building the tooling to move them into a monitor repo offsets that cost

John 59:59

yeah I agree with everything you said. I also think that it's important that companies understand if they want to do a mono repo there, somebody has to commit to it and take care of it, and help their teams understand how to use it, take advantage of it, expand its tooling troubleshoot it. That's also an investment. So yeah, it sounds like in your experience to you, you've had the facility to do that. Right to evangelia.

Majd 1:00:23

Yeah, I not only was building that tooling, but as we were transitioning things, I devoted myself to being more of like, almost like a floor manager, like, if anyone had questions, I really put an effort to drop what I was working on to help them Because ultimately, we're our tooling is meant to help these developers. So rather than continuing to focus on my deliverable, right, now, I had to put effort into like, Oh, this person has this question, even if it's small, like, let me not only unblock that, but now that I've talked to them, and saw what the problem was that they're facing, I have to consider that in my process. Right? Yeah. And it kind of becomes a good feedback loop. But it has to be centered on supporting these people who are using the things that you're that you're changing.

John 1:01:10

Yeah. And thank you for the for elaborating, because it's more than just setting up learner and go, there's a component to it that we have to we're talking about working together in the same space. So we all have to get along. And we all need a little bit of help to understand what's going on. So how to introduce mono repo into a company. I guess part of that too, could be like, what's the plan? And part of adoption could be when do you get your to your first attractor? So at what point does the mono repo feel go from feeling like a new thing that I might want to avoid? to something that becomes more obvious to me to adopt? I want my code to be in there. Have you considered that position at all,

Majd 1:01:56

I always like to use the metaphor of planting seeds. And sometimes, especially for people who have that fixed mindset, it's good to kind of, it's almost like inception, right? You need to give them make them think that they have the idea. So you present first, you know, hey, there's this concept called mono repos. And, and these are some of the benefits and oh, but these are some of the problems. And you know, we would never do it at our company, you know, well, internally, like winking to yourself, like, tell them, and then later, almost, almost immediately, it's kind of like learning a new word. And suddenly you start hearing it everywhere. All of a sudden, here's the problem that we're having with our CI, here's the problem we're having with this thing. Here's the problem, we're having, you know, what might really help us as if we had a mono repo. And you start realizing that you're not the one suggesting it, right. And that's how you end that's the thing as, as an idea starts to become more attractive to other people, that's when you can get that group adoption. Yeah, because it's different than then like you independently going in doing all the research, putting together all these numbers and using that to kind of get a bunch of people in a room who are resistant to change all at once to be like, Hey, I think this is a good idea. Because it just, I mean, it really doesn't work unless they're already leaning into that idea. And the only way they can lean in as they hadn't had time to actually think it through in their mind and to originate their their patterns around why it's a positive thing, as opposed to like, immediately, you know,

John 1:03:29

yeah. And I think it's a mistake. And and this is something I'm trying to think of, how do we get more people involved in the ideation process, for the sake of having ownership to mitigate the feeling of this was pushed on me, or I am forced to work this way, even though I may or may not agree with it. I don't really have, the only answer I have right now is I need to have that in front of forefront of my mind, at the top of any thing that big graph qL is, I think, is is an example, especially with well established organizations that are finding it beneficial in some pockets. It's really hard to break it out of that, because you're at we're asking a lot of people to think very differently about data and how you make present things to customers and build services. But how do you just kind of throw this out there? I know, this is a pretty deep question. But how do you like what are some ideas or ways that we can get someone let's say, you and I were going into a new company together, we see the opportunity, right? The mono repo pattern is here, it looks like it would be a good fit. How do we get more people involved in the conversation of getting to that decision?

Majd 1:04:45

I mean, ultimately, it has to do with relationships. I think, I think the first step, especially if you and I were new at this company, there's probably already people who have thought about this. There's probably already people who complained about some of the problems that they're That they're dealing with. And as new people jumping in, you know, how arrogant to be the ones to be like, right? I think we should completely overhaul our architecture, because I know better, you know, and, and I definitely had that feeling a lot with coming into coming into hellofresh. Because I was like, Oh, I just did all this infrastructure work, you know, put me on a pedestal because I know how to fix all your problems, you know. And it's, it's such a shitty attitude to have coming into a company. And I had to check that in myself. So really, it comes down to how you build the relationships and have the conversations, you know, independently and say, Hey, like, so? Like, what are the things that you don't like? What are the things that you that you're running into, you know, I'm new here, I just want to understand the bigger picture. Like what some of the history, I'll even share, like, one of the things that I really wanted to push for was for stronger, smarter components. And I mean, like with state, and that's something that that hellofresh rejected a lot. And then it took months before someone finally shared this history of this old package that you said, that still exists in some places that had a whole bunch of convoluted logic about all these different splits and variations because of designer and product changes based off of experiments based off of features that they wanted to do and try. And ultimately, I recognize the problem was that developers weren't saying no, right? And that it led to this package get blown out of going out of control. So rather than just immediately saying, Oh, we need to have these these components be smarter. It's better to understand the history and the story behind why it is the way that it is. And once you recognize that, and you can you can pinpoint the problem right now. I know, okay, well, they're having problems with people are not empowered or encouraged to say no, how do I? Now the question is, how do I convince them that and that's the next. That's the next problem to solve? I don't know how to answer that, because it's still.

John 1:07:03

So what I've, what I heard is, is ask, don't just jump in with with something as big as mono repo, right, don't pull it off the shelf, and, I guess, dictate or drive the solution. But instead, and this is a really long process, I think it's convenient for us to just say, oh, like, I know, this is gonna work, just just do it, trust me, that's way easier than instead of talking to the people that that change would actually affect. And then drawing parallels to what you understand is possible with using these such like strategies like a mono repo, for the sake of solving those problems. And there's there in working through that hesitation. But I also really like I like what you said about look for other people that probably already had the same idea. And maybe there's other people in the company or in your organization that have been trying to make that happen already. Because like, I can see that actually quite a bit when new people come into an organization. And they identify same similar issues that they have problems with. And they've solved those problems once before, they think they're coming up with something new. And then by the time it's presented, there's people like Oh, man, like we were trying to get make that happen years ago. So that's, there's a missed opportunity to capitalize on the thinking of other folks for the sake of getting more buy in, that can really just not only help achieve the goal, but drastically potentially simplify what it means to make it happen in the organization broadly.

Majd 1:08:32

So I'll share to my my small way of contributing in that way at hellofresh. early on was, was having some conversations around, like I mentioned before the ES lint configuration. enough people were like, Oh, yeah, it's so weird that we don't have the same configuration. Everyone was using, like the React app config, but there was so many, like, rules that they would override and extend and change. And I was like, or we could just have one and then just go through and change, you know, maybe still extend and change what we want. But at least then we have our version. And people were like, Yeah, that's a good idea. And eventually did encourage and help support getting it as far as it did get. It was still slow in the making. But again, it's still my first year at hellofresh. So it's not, it's not like I could just jump in and change everything all at once. You know, and I and that's not on me anyway, that's not what I was hired to do.

John 1:09:23

I bet there's going to be more people that feel like they own more of the ideas that are that are going into it. And I think honestly, like, in a lot of ways that's more powerful than just building a thing that most people don't want to adopt.

Majd 1:09:37

Yeah, even if you know that it's gonna it's, it's like, if only these kids would know what's good for them, you know, like, I mean, and that is the attitude because you're like, I know better. I know, once I build this thing, they're gonna they're and they adopt it, they're gonna improve. And maybe that's true, but that doesn't make it the easiest approach. You know, it doesn't make it the best approach at all. And it's not Yeah.

John 1:10:00

Well, it's been really great talking to you today we are at about time, unfortunately, even though I've got actually a couple other things I really like to talk to you about, maybe we'll maybe we'll do this again. So but before we break, though, is there anything you'd like to let the listeners know that's going on with you? Or, or opportunities that are available? Or how to reach you? Oh,

Majd 1:10:21

I didn't even think about that. I don't really have anything in particular myself coming up. I'm just trying to navigate COVID. And, you know, like, doing my thing, I know, there are some opportunities at hellofresh everyone's always welcome to look there at the careers page. And to reach out to me my I actually am very responsive on LinkedIn, although I'm very restrictive about who I connect with. So that my, my communities actually people that I know, which I know, isn't super common on LinkedIn. And yeah, otherwise you can, I mean, you can try to find me on Instagram, but my pictures are mostly just stupid stuff. I'm not really that active there. So reach out. It's, uh, I'm pretty easy to talk to, especially if there are any boot campers out there. I am a big advocate for the for boot campers and getting into the getting into the industry. So if anyone has any

Unknown Speaker 1:11:11

questions or

Majd 1:11:13

need some advice or some guidance, I'm always there.

John 1:11:16

Excellent. Thanks so much.

Alex Bachuk 1:11:19

Thank you. All right. Thank

Unknown Speaker 1:11:20

you all for for interviewing me. This is great.

John 1:11:23

This is our pleasure. Thanks so much. Thanks for tuning in to the pragmatically podcast. If you found this conversation interesting or helpful, we would appreciate your feedback. If you want even more content like what you just heard. Check out pragmatic lead comm if you have a story to tell, send an email to pragmatic lead@gmail.com and someone will be in touch. Thanks again.