Jenn Creighton talks with chantastic about component architecture, composition from a perspective of writing, mastering interpersonal communication, and feeling your feelings. She shows us how to save ourselves from the "apropcalypse" by leaning into age-old patterns of composition and organization.
Jenn Creighton — Twitter, GitHub, Website
chantastic — Twitter, GitHub, Website
Join the discussion Discord 🎉🎊🥳
Listeners of React Podcast are chatting on Discord!
Join us Thursdays at 10am CT for a friendly chat thru the latest episode.
It's fun, interactive and all are welcome!
Discord invite
AWS Amplify is the fastest, easiest way to develop web and mobile apps that scale.
Get started building a React app today, check out the tutorial on AWS Amplify today, visit awsamplify.info/react.
In over your head with a React or React Native app?
Infinite Red can help.
They are React Native core contributors who've been designing, building and shipping apps for over 10 years.
Learn more at reactpodcast.infinite.red.
Please join us in donating to the Equal Justice Initiative
Chantastic: Jenn Creighton, welcome to "React Podcast."
Jenn Creighton: Hello. Thank you for having me. I'm very excited to be here.
Chantastic: [laughs] I'm super excited to have you on the show. I wanted to have you on React Podcast ever since, I think it was almost exactly a year ago at React Conf in Nevada, where you gave your React is Fiction talk, which was amazing.
I was sitting there, and I was like, "Oh my gosh, I don't know if I've ever identified with the talk as much as this talk and felt so represented by the way that you were talking about React code." I was glad that it was you and not me because people were going to be like [imitates] , "You're doing it wrong."
[laughter]
Jenn: I had that fear when I did that talk. I was like, "Oh god." If you've never seen the talk, I do this thing where I make a little switch in it, where if you don't know that that's coming, you either think that I'm an idiot.
Chantastic: [laughs]
Jenn: Or you're like, "Yeah, that's the way to do it." It's either way, you're thinking something. Then I just switch it on you very quickly.
Chantastic: [laughs]
Jenn: I did have people messaged me that were like, "We were so afraid that you were serious." I was like, "It's OK, calm down."
Chantastic: [laughs] Wait, what was that switch? Could you describe it to me a little bit?
Jenn: I start off by building out a common like piece of UI, which is a navigation component. I go through, just a common mistake that people make where they try and make it as reusable as possible. Then the switch is really me telling you like, "We did a bad thing here." This just wasn't a good idea at all. Yeah, that's the switch.
Chantastic: I find those talks, extremely brave. One of my favorite speakers is Sandi Metz, and she talks a lot about composition. One of the tactics she uses is exactly what you're talking about. This is in her book, and in her talks, where she does it the way that you expect it to be done.
Then she's like, but this is bad and let me show you why, because this happens, and then you're like, "Oh shit, that does happen you're right." I love watching that stuff play out it's so much more engaging, I think a talk format to do it wrong. Then be like, "Oh, but there's an oopsie here and eustress."
Jenn: It's so much more effective than just being told that's not the way that you should do it, which is just very common in software engineering. Someone just walks over to you and says, "That's not how you do it, change it to this and it's better." Then they just walk away. You're like, "I have questions. Why? What? How?"
[laughter]
Chantastic: It is interesting, and that goes to one of those things that I hope that we'll talk about today, but that notion of show don't tell, which is something that people hear a lot or a saying computer science, but I think that you have an answer for what that means and how it maps to React really well.
Before we get into that, for anyone who's not familiar with you, tell us a little bit about yourself, what you're doing these days, what your role in your work, and what gets you excited about React?
Jenn: I am a senior staff, open source engineer at Apollo GraphQL. That is officially our name now. We changed it from the Meteor Group. We're now Apollo GraphQL. I work specifically on Apollo client. I joined that team -- oh, sorry, the pandemic really hurt my brain and time is weird -- April 2020. Before that...
Chantastic: [laughs] Deep in the pandemic, we were already, you joined during the thing, and it's no time has passed.
Jenn: I left my job. I literally gave notice, and my job was like, "Well, the pandemics hitting New York, We're shutting down the office, you can return your laptop." Never I still have that laptop.
Chantastic: [laughs]
Jenn: I haven't returned it. I have no ability to do. I can't get my stuff from the old office. Anyway.
Chantastic: Oh, man.
Jenn: Also, I was supposed to start at Apollo later. I was going to take some time off to travel and speak at a couple conferences. That changed.
Chantastic: Like, "I'm just free to start now then."
[laughter]
Jenn: Basically, I just wrote them and was like, "Hey, I'm going to get real bored if I don't have a job, and this seems like a bad idea. I'm going to start in two weeks. Sound good?" They were like, "Yes, that works so well for us, please, come aboard now." It was pretty good.
Chantastic: Awesome. Well, that is a project that a lot of people would be familiar with. What does it look on a day-to-day basis, working on the team that manages Apollo, GraphQL, all of those cool things that we like to use?
Jenn: Working in open source is such a dream job for me. I wanted to work in open source for a long time, but it's very hard to get a paid gig in open source. I was actually moving in my career towards this front-end architecture role which is what I was doing before I joined Apollo GraphQL because my specialty is crafting front end code basics. That's my specialty.
I've been working with React for a long, long time. I don't even remember. I think it's five, six years, something like that now.
Chantastic: Nice.
Jenn: I've been working with it for a very long time. It's definitely my framework of choice, and I love it. To be able to work on a project that's not React but is very React-adjacent, if you use React and you use GraphQL, you likely use Apollo-client, is a joy to have that be part of my day to day work.
Right now the project that I started on when I joined, is a complete reworking of the Apollo-client DevTools. They haven't gotten love in forever. I got to do my favorite thing in the world which is refactor an entire codebase.
Chantastic: How sweet. [laughs]
Jenn: I'm like I'm in heaven. Some days I want to work on something else but most of the time I'm like, "This is my jam. This is what I do, so please..."
Chantastic: This refactoring codebase, but then there's also you said DevTools. I'm assuming these are Chrome extension type things, that is maybe the most painful work I've ever done in my entire career.
Jenn: [laughs] You mean dealing with the Chrome and the world of the browser?
Chantastic: Yeah, all their DevTools APIs are just a mess.
Jenn: They are horrendous. Truly.
Chantastic: [laughs] Did your favorite thing outweigh the worst possible web development [laughs] platform you could possibly mention?
Jenn: Not as much. Devin, I yelled a lot. I yelled a lot because, for anyone who's never built something, using the browser APIs, what you quickly find out is, one the documentation is bad and incorrect. You can't rely on it.
You have to find other people's projects and figure out what they were doing and what your own project was doing. You find out that all the environments are sandboxed. What you end up having to do is you have your browser, talk to this thing, which talks to that thing, which will talk to your page, and then you will go back the way you came to the browser.
Chantastic: [laughs] Go leave some breadcrumbs so you can find a way back.
Jenn: Yes. It's not fun in that regard. You find all these things that normally if you didn't have this you could write some beautiful code for how these work together. You're working in an antiquated system and a lot of it's for security reasons. You are like, "OK, I'm going to..."
Chantastic: It's understandable but also you're still pissed.
Jenn: Yeah, you're still mad. On the other hand, it's a really interesting problem to solve. When I started working on the Apollo-client DevTools, what I noticed immediately about working in the codebase is, it's difficult to figure out where things are going and where things are coming from because of this structure.
My first challenge was how do I make it easier to work in this codebase. I came up with a system that talks to each other as a relay system, which is funny because Apollo-client and Relay.
[laughter]
Chantastic: We don't use that word here.
Jenn: [laughs]
Chantastic: You've to come up with another word for the system that you may have. [laughs]
Jenn: I didn't by the way, I call it relay.
[laughter]
Jenn: I don't know. I have no ill feelings towards Relay, I don't. It was what the system was doing. It's a relay of passing information on so I don't know. It was fun to build out and see and also to put in my pull requests. This is not the relay that you think it is. It's a different one.
Chantastic: [laughs] I think I might have gone for like, "Add Relay to Apollo."
Jenn: No explanation.
[laughter]
Chantastic: I guess you got to read the pull request you want to see what it does? [laughs]
Jenn: It would have been funny but I didn't want anyone thinking I was doing it to troll them. I promise I'm not. I want to call things what they are.
Chantastic: [laughs] This is what I want to go back a little bit or relay back to...
Jenn: [laughs]
Chantastic: ...something that you mentioned, which was your work doing architecture. I feel that's going to be the core of what we talked about today is composition in React architecture. A lot of people don't necessarily know what makes React components good, or why.
I feel like a lot of people also don't understand why we would have someone who considers themselves an architect versus someone who just writes code. There's a lot of questions around this. I would love to tease out what an architect does, but then also tied to React and how we write React code.
I feel like I end up doing a lot of the same work like React architecture work like working with teams to make sure that their stuff is composable, works well together, plays well with others and isn't going to hurt them in three months when they inevitably have to add more stuff to it. I'm curious, how do you see the role of architecture in a front-end codebase?
Jenn: I've always thought about it as, you are responsible for the health of the codebase. That goes into that point that you just said about making sure that things play well with others, making sure that things are going to be OK to be changed in three months. Not everyone has had the benefit that I have of seeing multiple React codebases and what happened to them over an amount of time.
You can see how you can get yourself into further and further holes and you just can't get yourself out of them without investing a lot of time. There is no company that I've ever worked at that was like, "Sure, you take that extra time. We don't need to get this to market at any point."
That is usually very unreasonable [laughs] unless you get into a system where literally you can't make a move anymore. It's normally less like you can't make a move anymore and it's like the health of the codebase has degraded to a point where making a move is just really difficult. It takes a lot more time to integrate changes.
A lot of architecture is about that, making sure that the ultimate health of the codebase stays up to a point and also that it's a codebase that people want to work in.
Chantastic: [laughs] Is that something people are trying to avoid tickets on. They are like, "Oh, yeah, I should probably do that because that seems like a high priority for the company, but like this is also on there and I could work at a codebase that doesn't suck?"
Jenn: Yes, 100 percent, 100 percent. I have worked in, oh god some really bad ones, some really bad ones where I just was like, "I can't. I can't work with this. You can't do this to me. I have to go. This is bad." It just makes everything so much harder, so much more harder.
Chantastic: It sounds like a lot of times your role is to...This is such a hard thing because it touches on this really hard thing to I guess make concrete which is time now versus time later.
Jenn: Yes.
Chantastic: I'm curious, I think this is kind of the challenge of the architecture role is, how do you actually communicate those things to people who don't actually care about the code? Like business doesn't care they just like, "I want this thing done as fast as possible." Most times the direct path is as fast as possible, but there's also that concept of technical debt.
It's like, "We can get there fast today, but we're taking out like let's call it like a five-week loan against being able to work on this thing in the future." How do you communicate that, think about it or even evaluate it? It's a very elusive thing.
Jenn: It's very hard to evaluate it and it's so dependent on so many different factors. It's really like what is your codebase currently look like and what actually needs to take like what are the steps you need to get this thing done? I always try and find the way, I say this in my React Inspection Talk and it's 100 percent true.
Your first draft is going to be pretty terrible and your second draft probably isn't going to be the right one. You are always going to be rewriting components. It's not about getting things right the first time. It's about, how do you build in as much flexibility as possible for later down the road.
That was a big part of my role as an architect, was looking at things and doing this like analysis of like, "Well, if we do this to make it a bit more flexible, how much time is that going to take right now?" Verses what I know is going to happen to this component maybe later.
Sometimes it was honestly about stepping back and being like, "OK, you want to build the component that what, you do that. I'll see you in a few months. You do that. You've got to learn somehow."
Chantastic: It's almost about like planting those seeds and be like planning the questions and then [laughs] being able being able to harking back to them in three months and be like, "Oh yeah, that's funny if only someone could have predicted that maybe it would turn out this." [laughs]
Jenn: It's like we were talking about earlier if...Oh god. I've lost my trail of thought. There's a difference between telling someone that something's going to go wrong and letting them experience what it means to have it go wrong. Sometimes you need to do that.
You need to cue it up with a like a little bit of foreshadowing of like, "Hey, you want to build it this way, you do it. You do it. Maybe I'm wrong in the end, but I've seen how this ends up going. We'll see how it goes. You do your thing." This happens all the time but the things that you just like...
I did it as a younger engineer too or someone like I would build something and someone would be like "You should have done it X way" I'll be like "I don't get it. I don't get it. Why are you saying this? You're overcomplicating things. You're really complicating the thing."
Chantastic: It could be so easy. Look, it's so easy here but...
Jenn: They were right because like later down the road it'll like...My favorite example of this is tooltips.
Chantastic: Oh gosh. You have a great talk where that you open with this example.
Jenn: Yeah, where you just add a tooltip to something and voila. Tooltips are deceptively simple so the first time you ever build one in a codebase normally what you're building is one tooltip that's going to show one way and that's it. You just hover on something, you get a little tooltip.
It's always in the same place, the contents really small and then what happens is that tooltip lives in that codebase, other people need it for other things and they start to layer on complexities. Actually, it's supposed to render on top now. Let's do a thing that it will render on top but in needs to actually go on the side now.
Remember that when it's on the side if we are on mobile, it's going to go off the side so actually we need to calculate and it just becomes a nightmare. I worked in a code base that had legitimately three different tooltips for three different use cases of someone having to they Gerry Gregg this thing to do what they needed.
Chantastic: Sure, you have this simple tooltip which is just like, "Oh my gosh, you just need a tooltip." Then you have the ones are progressively more complicated for those. [laughs]
Jenn: Yes.
Chantastic: You're like, "I don't want to have to opt in to the more complicated one because that's going to be a disaster but I mean if I have to, then I guess [laughs] we have to."
Jenn: I feel like everyone always starts, "Tiny little tooltip." I'm like, "Just wait. Just wait for that tool tip. It's going to like go really crazy."
Chantastic: [laughs] I think that's a really interesting analogy for the type of work that we're describing, which is so often, you are reaching back for what is the simplest that this thing could possibly be. Right now, your whole focus is in this world of this one component. You're trying to add all the complexity and all the cool stuff.
I know that, as soon as someone else is going to look at this, they're not going to understand it. It's not going to do the thing that they need it to do. Then, when they add theirs to your imaginary needs, now we're just chasing ghosts. This thing is impossible to work with.
A lot of times, it is just being like, "Hey, do we actually need that? Can we do without it without hurting your self-esteem that you made something that was trivial?" [laughs]
Jenn: Oh, my god, so much of engineering is about our own self-esteems.
Chantastic: [laughs]
Jenn: The pain we feel when someone touches our components.
Chantastic: [laughs] You talked about this show, don't tell thing a lot, and I loved it. It'd be a great time to dive into that now because we have a couple of analogies built up. How do you describe to people the actual reality of show, don't tell? We hear it a lot, it's one of those things that is just like this platitude that's floating around in our head.
I feel like once it's in that space, you could make it mean whatever you want. Just like, "Oh, no, I'm doing show, don't tell," and try to convince yourself that you are. What did that mean in reality from its origins of writing and all that?
Jenn: It's a well-known saying in writing communities that basically, you don't want to just tell your reader what is happening. You want to use more descriptive language to give them a sense of what's happening and let their brains fill in the gaps. If you're like, "I walked out the door. It was rainy." That's just like telling someone whatever happened to you. It's not very descriptive.
You know that you went out the door. You know that it was rainy, but it doesn't tell you anything about what mood that person was in, whether they like the rain or not, the environment around that. You could describe the scene so much differently like, "I walked out my door. I felt like the rain was coming down on me, and I just felt so sad."
Chantastic: [laughs]
Jenn: I don't even know how to do it now because it takes time to sit down and describe a scene. You're adding in the actual layers of what the scene would look like. There's a way of talking about how you step, how you trudge or how your body has weight, or how you go outside and you feel the rain on you and you feel your body lighten up. That's such a different way of talking about it.
Chantastic: Interesting because in the first scenario, you're saying what happened. That's really the only question that you're answering. The why, the how, and all those points of interest, the motivation for lie, "Why am I going outside." All of those things. What's encouraging you?
Did you want to just be in the rain? Do you resent having to go out into the rain to get your mail, which you're expecting some package, letter or whatever?
Jenn: There's multiple layers. I'm doing a terrible job being a writer right now.
Chantastic: [laughs] You're on the spot. That's never a good...
[crosstalk]
Jenn: I'm like, "Describe the scene."
Chantastic: [laughs] Let me get back to you in two hours.
Jenn: [laughs] Give me some time to write it down. I will have something beautiful for you but for now. That's very true of what it's like when you apply this to components because the first time you probably write something, you probably are telling more than you are showing.
The reason that this really came up in terms of React was because you hear constantly, React is declarative. React is declarative. People really still struggle with like, "What does that mean?"
Chantastic: [laughs]
Jenn: You get told it means that you can write components that resemble your UI and their structure. That you can have the header and the body but they're actual components. Most of the time, we're still relying on telling. That's mostly to be honest props.
Mostly we're relying on props to tell people what's available to them in the component, instead of thinking about how we should be breaking down our components in a completely different way and composing them together. That is the showing. The composition is really, how did you put those together?
When I look at this file, and I see all these components composed together, have you shown me what is on this page? Do I have to go into these individual components and read through all the props that I'm sending down to get an idea of what's going on? Props are very instructional. They're like, "Do this thing."
Whenever you're using a prop that's like, is, or, should or something like that, you are more often than not telling a component to change its internal structure somehow. You're telling it. You're not relying on composition at that point.
Chantastic: Interesting. I'm trying to think of some like, show button, whatever.
Jenn: Yes.
Chantastic: [laughs] Things like that, where it's like you have taken a declarative API, and now you're telling it what to do. You've made an imperative, do this, out of something that should be declarative. That's interesting. I don't know, I don't know if we're jumping too fast into the actual things, but I'm insanely curious right now. Do you have smells then around that?
Is it the props that use a verb? Is it conditionals? What are those things that you send up a flare, I guess, like, "Maybe we're not using composition right now."?
Jenn: Yeah. Let's first be really clear about what an anti-pattern is. It is not that you never do the thing. That is not what that means. That's another thing that people get very confused about. They hear anti-pattern and they think I should never do this. No, it just means when it's your natural instinct to reach for it, it may not be the right case.
You need to take a little bit more time to think it through and make sure that you're not making a really common error. Anti-patterns are very common things that you shouldn't rely on. That doesn't mean you don't ever do them. I say this, because it got me in trouble on Twitter.
Chantastic: [laughs] What doesn't these days? [laughs]
Jenn: Seems like, I love it. Some of the stuff that would ping a red flag for me is definitely those verbiage props because they're instructional. You're definitely telling a component to change its internal something and you're probably not relying on composition very well in that case. If else statements, sometimes. It's dependent because if it's one place in your component, maybe not.
I often have seen components where there are multiple if else statements. Sometimes a switch statement, if you're using a switch 100 percent. No, you probably should not be doing that. In that component, you should probably be breaking things down differently. Those can be common things where you're like, I feel a little uncomfortable with what's going on here.
Then the other one that we talked about previous to starting this, but was sending in a component as a prop, which is super common. It's even mentioned in the React docs as, you could do this. Like, sure, you could, but did you want to? Most of the time, probably not.
Chantastic: Interesting. Describe this to me a little bit, what might, a concrete example of passing in a component as props? Even me who is so excited to talk with you about composition, not even resistant to the topic at all, I feel like, "Oh, wait, but wait a second. But, wait though. Wait, though really." [laughs]
Tell me, build up a concrete example for me of what this might look like as passing a component in as a prop?
Jenn: The way that I've seen it most commonly used is when you want to reuse some UI structure that it doesn't really take in any data. It's just your layout, basically. Using it for, "Oh, I have a layout with a sidebar, a header and a main area. I just want to pass in different components that will get rendered in those places, because they need to be a little bit different each time."
I'm not a fan of that. It's not wrong. I feel it's going to serve you so much better to use children in that situation and to build out your individual pages. You're relying, when you're doing that, on something else passing in the component for you.
There's no harm in you creating separate page components that will hold a sidebar, a header and a main, and then put in what you want that page to show in there instead of passing in the component. Then when someone opens up the file and they look at it, they can see what belongs in that specific page. I just prefer my engineers to be very clear about what belongs where.
I don't care about the fact that I've had to pull in the sidebar into three different files. That doesn't bother me. People do it a lot to avoid having to do that. They're just like, "Well, we just have our layout component, and then we'll just pass in components." You can do it. It's a little unclear though for the engineer.
Chantastic: Yeah, I'm totally tracking with you now. I was thinking about an as prop, where you would send in a component to another component that it might render as. I was thinking that way. I am fully onboard with you because those layout components, they drive me crazy sometimes.
They're like dark boxes. You don't know what it's supposed to do, but you have to read the docs, put things where they're supposed to be. It's almost like someone telling you to shut up and just trust me, which is not helpful if you have to do something else.
You have to start over effectively if you need to change that thing at all, or add a bunch of new props, which I think you have an amazing term for this.
Jenn: The apropcalypse, best pun I've ever made. When I made that pun, let me tell you how many people I told. I pinged every front-end engineer I know. I was like, "Guess what. Guess what?"
Chantastic: [laughs] It's great. If you made no other contributions to React, this would be enough. You could hang your hat on apropcalypse.
Jenn: I could've stopped there. Why go on? I peaked with apropcalypse. Why continue, truly?
Chantastic: It's just so fun to say too, apropcalypse.
Jenn: It just makes so much sense. Oh, my god, so many components, so many problems.
Chantastic: It's true. It's interesting too. My feeling is that a lot of this comes down to trust, I guess. Do you trust the people on your team to have the same fortitude in process to make something good? A lot of times, these closed components, it's a lack of trust.
I can't trust you to compose the sidebar, the heading, and the main content areas together yourself, so I'm going to do it for you, take away all that control, and then give you these three bespoke props that I decided were well meant.
Jenn: Yes. I'm going to lock it down so this is the one way we do it. That's true. That definitely is part of it. People try to pretend in software engineering. We all feel like we're little robots, like, "I'm a little robot. I made my component. You can't tell me that it's bad because I'm a robot." "No, you're human." Also, we don't always admit that what we do is an artistic endeavor.
We are creating things all the time. Guess what? When you create things, they are some piece of you, you don't want people messing with them. I know that feeling. This whole idea of composition is about allowing people to mess with your stuff. You're going to have to let that go. People have to be able to mess with your stuff.
The more you lock that component down in that way, the less somebody can do something else. You can pass in a component, but you have to pass in one component, remember, because of React. You can't do other fun things with that sidebar. You can't change certain things. You get locked down. It's not a very pleasant experience in the end. We forget how much we are coding for other people.
Chantastic: Absolutely. It's interesting, because it feels like if you're writing just for yourself, you could just predict how you expect it to use these things and whatnot. One of the things that makes software so challenging is that it is much more akin to making a movie or something that requires a lot of collaboration on different fronts and requiring experts from different fields.
You bring up such an interesting point. My introduction into composition in React was just how hard it was to implement designs if the developers had gone first, if they had written all these components. Now there's all these boundaries that they think are right. When it was just HTML, we just move things around. Now there's different files, different components.
You have to pull back the brush of all these bespoke prop APIs and try to relearn web development for the first time again. As you were talking about with children, you go back almost to that, "Hey, let's try to get back to the composition that we had with HTML before," which was a good playground, workspace, and collaboration space that worked for this style of heavy collaboration.
Jenn: If the developer makes the component and then you discover that the design has that one small little tweak when you're on this page, which inevitably happens. It is always, wow, under this one special circumstance, we're going to show a dot, not a triangle.
[laughter]
Jenn: There's probably really good design reasons for it. We're not doing it because we already built it with the circle. We're not doing it. This idea of composition of using children and stuff is about pulling out the pieces where they actually belong. Is it just a layout component? There is no reason to lock it down with a prop and sending in a component.
I see this happen all the time with modals too. Modals need to contain a lot of different UI. We just do a thing where we pass in a component to a modal, but you didn't need to do that. You just take the modal, and you wrap it around the thing and your children, it's there. You can do whatever you want in there. You're not beholden to it.
You also get all the information that you would get from the more above parent components passed down. It's harder to do that if you're passing in a component as a prop. If it relies on anything inside of that sidebar, layout, or modal component, you're screwed.
Chantastic: Yeah, because the ownership changes as you move around.
Jenn: Yeah. Ownership is a big topic in React. I just don't think we talk about a lot of who...
Chantastic: We don't, yes.
Jenn: ...owns what and why. It's why it trips people up on state and props so much. That's my theory.
Chantastic: Yes, I totally agree. For all of the things that we do talk about in React, talking about ownership is not one of them. It is one of those things that as you go down this path that you're describing of using children more and bringing in components as opposed to having components that know too much and you pass things in as props.
I feel like you start to realize that ownership model a little bit better. You have to do less nonsense to connect the data...
[laughter]
[crosstalk]
Jenn: It is utter nonsense sometimes. [laughs] That is such the most perfect word for that, of like, "You just have to do a lot of nonsense to get these things, chat and talk, and do what you want."
Chantastic: It's funny we opened about the DevTools APIs because that is all of that nonsense, but it has a reason.
Jenn: Yes.
Chantastic: We have created that nonsense of these relays for no reason in a React, except for the fact that we thought that they should be a component instead of just composing them together the way that we have for the last 20 years.
Jenn: Yeah. For no reason, or for a reason that we think is a good reason. When we learn about declarativeness, what we're told is something about reusability. We don't have a very good sense of what that means. We just think it means making sure [laughs] that we get as many changes available in one component as possible, like this component can be our Swiss Army knife.
Chantastic: [laughs]
Jenn: It can do whatever we need it to do. That way, we only have the one component and the one file. We feel better about ourselves, but we don't. Then we use the Swiss Army knife and we want to tear our hair out. It's not a good system. Any time, you're like, "I need this component to do X, Y, and Z, and B. It need to also do B."
Chantastic: [laughs]
Jenn: I promise you, there is a better way of doing this with composition. You can pull things apart. You can have components that do very similar things, but just a little bit differently and it's totally OK. It is fine.
I don't know where we got into this world of like, "Well, if they do remotely the same thing, they have to be the same component. Then I'm going to give them a prompt to tell them to do that one thing a little bit differently." No. You're setting yourself up for a world of hurt. You don't work in a vacuum. You work with other people. They're going to make changes.
You can't lock down your components.
Chantastic: [laughs] We're in it now.
[laughter]
Jenn: This is so cathartic for me. I haven't talked about this in a while. I've been in the pandemic bubble. Now I'm just like, "Let me tell you what you're doing wrong. There are people and we have feelings."
Chantastic: We're talking about ownership for the first time ever. [laughs]
Jenn: Ownership, you have to think about the ownership, whether you own the component. Who owns it? What do they own? Who are the parents? Who are the children? Who has the state? Who gives permission to change the state? So much.
Chantastic: So much to think about all these little components, all these little components. I want to talk about the practical effects. This is something that I can never adequately describe to people. I hear all the time these notions like, "Oh well, if we just do it in this one place then we only have to change it here and then it updates everywhere. Everything is great."
I want to hear your take on that. I want to push you into that corner a little bit more because...
[laughter]
Jenn: You're like a rabbit raccoon here. Like, "Here raccoon, get in the corner. Get in the corner raccoon."
Chantastic: [laughs] Even just hearing that as like the case that we're not trying to do, it raises up something in me. I'm curious like, how do you think about that? What do the things that you see as the failing of that? How true is that statement?
Jenn: Oh my god. How true is that statement? Look, everything is really dependent on the codebase that you're in, what was set up before you came there, what the system is like working at your place. I've had a lot of jobs and I say that so weary because they all came with different codebases that I had to figure out why I liked them or why I didn't.
The ones that I found that were the mentality of very dry. We have one file and that is where we make the changes. It almost always resulted in a lot of friction. You almost always had a use case that you needed to somehow again do some nonsense to to try and workout. It's a really beautiful idea. I get it. It is.
Chantastic: [laughs] The notion is so lovely.
Jenn: Isn't it just like the most lovely idea where you're like, "Yeah, this could really work, right?" It's amazing. In a lot of ways, we make a mistake of saying that this is a technical decision, that we want to do this for technical reasons. We make up a lot of things about testing or just a file and stuff like that. Do you know what it is though? It's really a strategy to avoid communication. Ultimately.
Chantastic: Fire right there. [laughs]
Jenn: It's a strategy to avoid communication.
Chantastic: Repeat it for those in the back.
Jenn: Did you hear that people?
Chantastic: Oh man, it hurts. It hurts but it's true.
Jenn: It's so true. You're trying to avoid having conversations with people and what you end up doing is having worse conversations with people because you have to go to the people who last changed the file, or who need the special thing.
If we built our system where it was more composable, where we didn't worry about this as much, the having the one file with the one component that is our Swiss Army knife, or what have you, composition is, to be honest, is an easier way of also having communication with people about the flexibility of systems. "Hey, you built this thing. I'm going to borrow it. Cool?" "Great."
[laughter]
Jenn: It's just so much easier, like "You built this sidebar. Cool. I'm going to wrap it around this other component because I've got a thing to develop." "Great, nice talking to you." As opposed to, "Ooh, so that thing I need..."
[crosstalk]
[laughter]
Jenn: " Hey buddy" That person being like, "No I've built it this way, so we're not going to touch it."
Chantastic: "Yeah, I can't do that, sorry." [laughs] I don't even have the words. The way you put it is so brilliant, a strategy for avoiding communication. It is so true. Even if you don't design it with that intent, I have felt that way. It feels like, "Oh, no, no, this is done."
Jenn: Yeah, this is done.
Chantastic: Which totally betrays the notion. It betrays that notion of like, "Oh, well, we can update it here and then fix it here and updated everywhere." It's such a fascinating betrayal because the reality never matches up with the sales pitch. That is something that's super frustrating for you, because like you said, the notion is beautiful.
In reality, it's almost a way of saying like, "OK, I'm going to do this once and for all and, in fact, we will never update it unless I feel it's necessary."
Jenn: We're going do this once and for all. It is done with a capital D, we don't touch it. No, that's not how it works. This is how you get also. I swear that you can go into a codebase and you can tell how bad the communication is in a company.
You can absolutely just be like, "Wow, y'all don't talk to each other. I can tell this, because one of you built the done component for how we're going to do things." Another one is like, "No, I really need it to be this way so I'm going to sneak off. I'm going to build another one."
Then the new engineer comes into the company is like, "Which one do I use? I don't know. I know, I'll build a third for my use case." There's this fine lying between like, "We don't need to be dry and also, we don't need six components that do essentially the same thing.
There's probably a better way that if we all put our heads together and talked about how these need to work, that we could figure out a system that's going to work. We could talk to each other about it, we could relay the information to the rest of the team so they know, oh, now we have this thing and this thing, and this thing. If you want to do this, use this, if you want to do that, use that.
Chantastic: I like this notion of that being a symptom of bad communication, and solving it with communication. You haven't offered a technical solution. You're saying like, "No, well it's a sign that you need to just communicate better and have better strategies for talking to the other humans that you work with. [laughs]
Jenn: Strange idea I know. I worked in some code bases where that had happened so many times. I could tell that the teams were not communicating with each other. There were multiple engineers that wanted to own large parts of the system and weren't comfortable with other people having input into those systems.
It is a thing that happens very commonly where you're just like, "This is my baby. You don't touch."
Chantastic: In that way the component boundary becomes like a castle, or like a moat, almost where it's like, "Oh, no, only we're allowed in here. Sorry you can't be in here."
[crosstalk]
Chantastic: It's funny. Oh, sorry. Go ahead.
Jenn: No, no, you go.
Chantastic: I was going to take it into, I [laughs] I love to fit this quote in anytime I can. You just had the perfect setup for it.
Jenn: Oh, you're welcome.
Chantastic: [laughs] You talked about dry, resulting in friction. One of my favorite things that Sandi Metz says in some of her talks is she says that when they do pairing with companies and investigate the code, they'll say, "This code is so dry that it chafes."
[laughter]
Chantastic: I think it's such an interesting in that because you never hear about dry in a bad light, but as you mentioned friction, these [laughs] are not pleasant things. It is interesting, when you talk about composition, you talk about all of the good things in communication that you would get by avoiding it, to think about it as like just dry, itchy friction.
Jenn: It is, I'll just say one of my...I have a lot of pet peeves in engineering to be honest with you. I have a lot of strongly held opinions that I will...What is the thing? Strong opinions weakly held?
Chantastic: Yes.
Jenn: I have a lot of those. You can change my mind on some of them. One of the ones that actually kind of strongly held is this notion of dry and how much I hate it. When someone says it to me, my whole body just locks down and it's just like, "No."
Chantastic: No, that's not.
Jenn: Because I was told it when I was a young engineer. Like, "Oh, you need to dry this thing up." When you listen to that and you just do it mindlessly, you're not really considering all the factors involved. Some of the time, I was in the middle of refactoring something. That's not the time to dry something up is when you're in the middle of a refactor. Absolutely not.
I always liken it to like you're reorganizing your closet and so you pull all the things out of the closet first and then you organize the closet, but you don't do it like piecemeal because you're just going to reorganize your closet at some point. You will find a shoe box of things in the back and you're like, "No, I don't have a place for this." That's what it's like. This overreliance on dry.
It serves other technologies maybe better, but when you're talking about front-end and UI, I just don't think it serves us very well. Ultimately, our designs are not dry. Our designers are not designing with dryness in mind. They're designing with the user in mind and that just isn't a very dry scenario.
Things need to change for different scenarios and you need to be more flexible in a lot of ways. Flexible UI is like just guess.
Chantastic: [laughs] No, it is true. I think that that illuminates level of thinking that I love to see in developers and engineers is that holistic mindset of thinking about the user, thinking about the design.
If you spend any amount of time really understanding a design, how certain designs are adaptable and how they necessarily need to change for different layouts and scenarios, you start to think about your code differently. You'll be like "I was obstructing around the wrong concept." Like, "These things are the things that are the pieces that are actually reusable."
I know we are headed towards the end of our time and I wanted to ask you...As we come to a close, I want to talk about the actual emotional work of coding.
Jenn: Oh god.
Chantastic: [laughs] In this "React as Fiction" talk you end with the idea of the pain of revision. [laughs] I think that we feel that very strongly when people attack or it feels like they're attacking our code, or we have to revisit it and make it do something else, or the design changes, we feel that pain. I'd love to hear more about what that means to you and your strategies for combating that.
Jenn: The reason I said, oh god is because in early November I am giving a talk at JSConf Mexico online called, "Your Emotions are not an Anti-pattern." Just funny because I talked about anti-patterns earlier.
Chantastic: Nice. Amazing. [laughs]
Jenn: It literally is one just like you have emotions, you are a human. The stupid thing where you try to be logical over emotions is dumb and also there's no scientific proof for it so hot. [laughs] That's isn't one-line synopsis too long to read. The second half is building up an emotional aid like tool kit that I have developed.
A first aid kit for dealing with emotions because they actually come up in our job in every single respect. When I was a younger engineer, I was really pushed into this line of thinking that my feelings just didn't matter it was the code that mattered, and if I could stop being an emotional human being which is a stupid idea.
Chantastic: Robot. You've got to get to a robot. [laughs]
Jenn: You've got to be a robot?
Chantastic: Yeah.
Jenn: That I would be a better engineer. That my ideas will get taken more seriously. I just really thought I would write better code. Then I just emotionally plummeted, just couldn't handle my emotions anymore because I stopped feeling them. [laughs] My first word of advice on any of this is, you're going to have to admit that you're human and that you have emotions.
You're going to have to actually feel them. It is very uncomfortable I know this, but you're going to have to get used to it because if you cannot feel when they're happening in your body and you don't recognize that you are just an emotional being, you do a lot of things that are terrible to other people, accidentally. You don't mean to.
You're not a bad person but you've stopped realizing that you feel certain things. You stop realizing that you feel a certain way about the code that you wrote. It took me a long time to be like, "Oh, I'm very protective of this code and I don't like you touching it." The first step is admitting it, knowing when it's happening and then taking some time to like, "You know what? You can go feel it."
It's OK. It's not going to harm anyone if you go like...Right now also we're all working from home, log off for a few minutes. Take a breath. Be like, "I feel shitty. I feel shitty when someone changes my code. I feel shitty because maybe it meant that I did the wrong thing."
Also the chances that you're going to do the 100 percent right thing, you're going to build the right component for all situations is ridiculous. If we really wanted...
Chantastic: [laughs] For all time too. Let's not forget and for all time.
[laughter]
Jenn: For all time because if we really wanted to, our whole entire application could be one component and we just pass down props, but we don't do that. We don't do that for a reason. It's really difficult. It doesn't make sense. We're supposed to be breaking things apart and having composition. Things need to change and it's not really a value statement on you as an engineer.
It's really not. The thing that you need to figure out it's like, "Well, what could I take from that into the next thing or what worked well that I'm going to do again." Think of it like a feedback loop that is happening and what can you incorporate the next time. Feel bad if you need to feel bad. It's totally cool. You're fine. I've had days where I didn't feel good about somebody making a PR comment.
Then I was like, "They are wrong," but they were right. It's cool. I think also just like really, really recognize that what we do is very artistic, very creative. You are literally putting yourself into it. No one goes into this job built a component and is like...No, I shouldn't say, "No one." Some people go in, build their component leave and don't think about it. I wish, I was one of those people.
That sounds really, really, really nice.
Chantastic: [laughs] It sounds great. It sounds delightful.
Jenn: Oh, it sound so good.
Chantastic: Not having your identity attached of you ask a character for a request.
[laughter]
Jenn: The fact that we have our identity attached to these things is kind of silly. You are building something, you're building it with your best intentions, knowledge and things like that. It's just really hard not to feel that way. A lot of us go into our jobs, build the component and the next day, we're my baby component, my baby component. We love it.
[laughter]
Chantastic: Time to present my baby to the world. [laughs]
Jenn: Yeah. [laughs] Then you get this horrible PR [inaudible 54:05] and you slide into a depression. The more that you can work through that emotionally, realize it's happening, deal with it, and find different emotional cues in your body of it happening and how to deal with it, the better you're going to be. You're going to be able to be a more flexible engineer.
Maybe you'll get even better at communicating with people, which is a big deal.
Chantastic: [laughs] That is incredible advice. I don't want to call it simple because it's not simple, right?
Jenn: It's really hard.
Chantastic: Yeah, it's really hard. It really does cut to the core of like, "Hey, you're a human and it's OK that you're sad that nobody likes your code." [laughs]
Jenn: It's OK. When someone says, "This wasn't well-built," it's OK. It's all right. You can feel bad. I give you permission to feel bad.
Chantastic: [laughs] Yeah. I love that. I'm definitely taking that into the rest of this week for myself. Thank you for encouraging me to feel my feelings this week as I...
Jenn: Feel it. Feel it all.
Chantastic: [laughs]
Jenn: We're in a wild time too to be feeling your feelings.
[laughter]
Chantastic: Yeah. It's a deep well of feelings right there, right now. [laughs]
Jenn: [laughs] Yeah.
Chantastic: How can people find you online and find that talk that you're about to give, because I have a feeling that's going to be another banger?
Jenn: [laughs] If you are attending JSConf Mexico on November 2nd, 3rd and, 4th, I'll be speaking on the 2nd. You can watch it then. It will definitely be online later. I will also post it and the slides, when available, to my Twitter account. That is where you can mostly find me online. I don't tweet everyday, but I am on there. I'm a lurker for sure. My handle is @gurlcode, girl with U.
Chantastic: Awesome. I don't know if we'll get this out beforehand, but we'll definitely share the fact that you are talking with people. Hopefully, by the time it goes live, no matter what, we'll be able to link to that video and let people know about it. Jenn, thanks so much for being here. This was a blast for me. I appreciate all of your time.
Jenn: Thank you for having me.
Chantastic: This was great.
Jenn: Oh my god! I had so much fun.
[laughter]
Chantastic: We'd love to have you on again sometime, and we can talk more about feelings.
Jenn: Yes! All the feelings, all them.
Chantastic: [laughs] Thanks, we'll see you again soon.
Jenn: Bye.