Making People Happy with UX Developer Jenell Pizarro

EPISODE 52

[INTRO]

[00:00:09] BH: Hello, everybody. Welcome back – Wait, not welcome back. All right, try again. You know, I had to screw up the first time.

[00:00:16] AC: Just Ben.

[00:00:17] T: A lot, it sounds a lot and so hard. All right.

[00:00:19] BH: All right. Here we go. Hey, everybody and welcome to Enjoy The Vue. I’m Ben. Today on our panel, we have Ari.

[00:00:26] AC: Hello.

[00:00:27] BH: And Tessa.

[00:00:28] T: Hi.

[00:00:30] BH: Our special guest for this episode is Jenell Pizarro. Jenell, would you like to introduce yourself?

[00:00:36] JP: Hi. I just waved. That's fun. Hello. I am Jenell. I consider myself a UX developer. I'm here. I'm excited. I don't know.

[00:00:55] BH: To start off, I'm really curious, what does being a UX developer mean to you? Because I think this is a title that doesn't really exist until recently.

[00:01:03] JP: Yeah. Essentially for me, it means that I really like accessibility and making sure that users are happy, and that they get surprised and delighted, or completely don't even realize that they're actually using the application, which is my favorite. I love it when a user is just like, “Yeah. I did this thing and I did that thing and then I went to the movies and I came back and that was it.” I love that they completely just disregard that they haven't even used the application. That's my favorite. Yeah. That's my goal in life is to ensure that people forget that they're actually even using the application, because it becomes such a normal part of their life, that it just becomes second nature.

[00:01:55] BH: I have to guess. Having come to the title of UX developer, so what was your journey like into coding? Because most people with traditional CS backgrounds are usually software engineers. I'm curious what your background is that led you to this hybrid role, which I'm in love with, by the way.

[00:02:11] JP: Cool. Once upon a time, I used to be a bartender for many, many years. I did that, I think, for five years. I managed bars and bartended like a champ. Never drank. Fun fact about me as a bartender. Difference as a developer, I started drinking heavily as a developer.

Yeah, I started as a bartender. Decided somewhere around the age of, I don't know, I don't even remember, I didn't want to bartend anymore, because it's not something that was fulfilling my life that and my degree that I went to school for was radio broadcasting. It was just everything. I actually just quit my job. I was managing a bar at Universal, and gave them a quitting cake. I printed my resignation letter on a cake. It was like, “Hey, I'm leaving. I'm going to go learn how to code. Bye.” I moved to a whole different city at St. Petersburg and learned how to code through the Iron Yard. They have that boot camp.

Yes. I did that and loved it. I thought it was going to be a super simple like, “Oh, I'm just going to do this on the side. I'm just going to make a little makeup app on the side,” because that's what I wanted to do. I wanted to make a makeup app. I was like, “Yeah, it'll be fine.” Then I could just live my life the way that I'm going to live my life. I realized, this is really cool, really fun. I really enjoyed JavaScript. It was my favorite. More halfway in the middle of somewhere, after I stopped crying about Flexbox, I think I found David Khourshid and his CSS Husky. It made me so happy and I was like, “I could just make things like this with code.” From then on out, I was sold and I've been coding ever since. This is my job now. This is what I do. Don't anybody talk to me about making alcohol for anybody else, but myself.

[00:04:29] BH: That's amazing.

[00:04:32] T: I'm curious what everyone else's titles are. Also, Jenell, if you picked your own title, how did you decide on UX? Because for example, I've been a GUI software development engineer. I've been a UI developer. I've been a UX/UI developer, all the UI/UX names. How about you, Ari? You’re laughing at me. What's your titles?

[00:04:53] AC: Currently, I think currently, technically, my title is full stack/front-end engineer. Though, if we're being honest, I'm really just a front-end engineer. Then previously, I was a UI/UX developer. Then at that same company, I was senior UI/UX engineer.

[00:05:12] T: Ooh, and upgrade when you become senior.

[00:05:15] AC: Yeah. No, I asked for the change. Because engineer just sounds fancier.

[00:05:22] T: It’s better. Ben?

[00:05:24] BH: Yeah. For me, I've run the gamut. When I started out, UX developer was definitely not a thing. I was really trying to make it a thing, but just didn't exist. I was technical consultant, front-end developer, then of course, developers don't get paid as much as engineers. Just front-end engineer made a difference in salary, which is weird. Then I did the UI engineer bit. I think I got the UI/UX title for a little bit, too. Currently, my title is developer experience engineer. That's the closest I've come to – because for those who don't know, my background in psychology. I've always been trying to find ways to merge the UX passion into the tech.

Yeah, I think this is the closest I've gotten, so I'm really excited that Jenell and others are also pushing the UX developer position, given that it did not exist when I first entered the tech industry.

[00:06:09] JP: I love that. I mean, technically on paper, I'm a software engineer, but I just tell people that I'm a UX developer, because why?

[00:06:17] BH: Yeah. Own it.

[00:06:19] JP: Yeah, that’s a good idea. I like making people happy. Why say that I'm going to do stuff that doesn't make me – like, “Oh, I'm just going to write itineraries all day.” It’s what I do, I write itineraries. No.

[00:06:32] T: Raving job alert.

[00:06:33] JP: Yeah. [Inaudible 00:06:34].

[00:06:38] T: What would you all say, is the difference between UI and UX? Or Is it worth defining a difference? How big is the overlap?

[00:06:49] BH: I'll start. I definitely think it's worth defining a difference, because I've seen, especially in the design community, being a UI designer versus a UX designer, it's very, very different in terms of your responsibilities. Even within I think, the UX realm, there's prototyping versus research. That's almost completely separate disciplines. For me, I think it is worth differentiating those skill sets, not necessarily on a pay scale, just from a skill set grouping, like information architecture perspective.

[00:07:17] T: How would you differentiate them then?

[00:07:20] BH: As far as generally speaking, I think, I would say the UI developers are the ones who clearly focus more on the – as the name would imply, the user interface. Making sure designs look and feel a certain way. Basically, executing on certain animations and those things. Whereas, I think the UX developers are focused more with collaborating with the UX designers from that research. What happens when we think of like, do the models make more sense? Do sliders make more sense? I think they're the ones that are involved more, or more interested in those conversations.

All of us end up being involved in those conversations, more or less, but it's about where's your interest in thinking about and solving these kinds of problems. Because as for those of us who have done work with animations, it's a deep rabbit hole to dive into how next tick works, how to make sure things trigger at the right time. That work is very different from whether we should do animations at all, or what types of animation. I think that's in my mind, that is the basic differentiator between the two.

[00:08:19] JP: Yeah, I'd have to agree in a lot of instances too. Creating an interface doesn't necessarily tackle the why. I think user experience definitely tackles the why and should you. Should this be a form, or should this not be a form? Or does every field actually need to say required on it? Or can maybe two of them say optional, and we assume that the user is going to go through the entire form? Those are questions that user experience developers are asking, before they even code, which is awesome.

I think, having a user experience developer and the user experience designer is really important, having the symbiotic relationship of a designer and a developer together, because you create more of a holistic questioning each other. Not in a bad way. You're never like, “Oh, you're the worst developer ever. You're the worst designer ever.” It's not like that at all. It's very much like, do we understand how our users are going to use our product? If we don't, how do we come together to ask the user how they would use it? Or can we monitor how a user is using it now, to see if maybe we can make their life a little bit easier?

You come together doing that, as opposed to working separately, which I think happens a lot. Where the designer is like, here is the design, you as a user interface developer would just implement it right and call it a day for asking deeper questions, I think.

[00:10:01] AC: What exactly is the difference between a UX designer and a UX developer?

[00:10:09] JP: I think that's a good question. In my experience, I think a UX designer is someone who is a lot more proficient at Figma and Envision and sketch and all those cool things. Because personally, I am not gifted in those areas.

[00:10:25] AC: Me neither.

[00:10:27] BH: Same here.

[00:10:27] T: It gets pronounced jifted, just saying.

[00:10:35] JP: Yeah. I am not proficient in that. I can make an SVG here and there to make animations and things like that from an SVG. The beauty of design and creating with those tools is just an art that is beyond me and it's so beautiful and I can't grasp that. It's awesome when other people can.

My interpretation of your artwork is what makes me a developer, a UX developer, as opposed to a UX designer. Does your art speak to the actual user, is how I – I make your art become a reality. That's how I bridge that gap, is UX designer is the art and the meaning behind the art. Whereas, UX developer is the actual implementation of said art and making it a reality.

[00:11:39] T: That makes sense. I don't know why this popped into my head as you were saying that, but you all know the meme about front-end and back-end, or full stack developer with the horse and part of it is rendered really detailed, and then part of it is like a cartoon. I imagine that was the designer’s mock, and then the developers, the Dr. Frankenstein, that really makes a real horse that looks like that. I was like, “This is horrifying.”

Yeah. I feel like, when it goes from design, to development, to user, there's a lot of different discussions there that we might all have in common. I'm curious what kinds of arguments, or conversations that people have at work around UX. For example, Jenell, you mentioned earlier something about validation. I remember on Twitter the other day, I saw someone screenshot a form with a name input, and their name was Sam, or something; really short. It said, the name was invalid.

A few weeks ago, we were talking about a feature on the app I'm working on, where users can take notes. There was a comment about how the users were using the notes wrong, because their titles were really long. There's probably definitely a divide somewhere between where the user is trying to do something that the product just wasn't designed to do, versus the user doing something that the product was designed to do. I was like, “What's wrong with having long names? That seems more like, we haven't accounted for that problem.” Yeah, I'm curious how these kinds of discussions play out on everybody's teams.

[00:13:08] JP: For us, it happens – For different teams, it happens differently. We could catch it way later, which is super fun. The team that I work on now, the application is aged. Is the best way, I can say it. It is aged like a fine wine. There are things that our customers have wanted from day one, that maybe we implemented very early on, but now doesn't necessarily make sense.

A user will always find a way to get to what they're going to do. Whether or not that's a full-on workaround, where you're like, “Wow, I didn't know that that's how you used that feature. That is not how it was intended to be used. That's cool.” They will always find a way and it's awesome to see why they're doing those workarounds and how did we fail to give them the best experience possible. When you're talking about the title thing, or using the comments and things like that, we had something very similar to that, where users were creating notes in a title, instead of creating notes, where notes – there's a discussion tab. They're putting their whole title of document as a comment.

Yeah. We're like, “Okay. Well, how do we make comments more available to our users? Because they're clearly, they need this feature more visible.” Yeah. I don't know if I answered the question.

[00:14:52] T: Yeah, it makes sense. It makes me think of that meme with the desire path, and then the actual path where there's a built-in road, but then it's faster to just walk across the grass. Over the years, the grass wears away.

[00:15:04] AC: Yeah. I'm on the other side of the app journey, where we are just getting to MVP. I feel, I'm often feeling the need to advocate for not limiting the user at this point, because we don't know how the user will interact with the app yet. People were proposing for example, on a data visualization, limiting the user to only select comparing four different organizations against each other, out of a list of say, 20. I said, okay, but what if we let them decide how much they can handle visually? If we find that they're overwhelming themselves every single time, okay, maybe then, we talked about limiting it.

I think, when you're first building an app, I think it's important to leave the borders open, because it's really hard to validate use cases when no one's using it yet. I feel your job as a UX developer changes depending on where you are in an app development cycle.

[00:16:17] JP: Full-on agree. I think it also changes by what company you work for, or not company you work for. I feel if you are in a startup, it might be a little bit different than working at a corporation, versus freelancing, versus consulting.

[00:16:40] AC: I think another thing I find myself doing a lot right now is trying to be the ambassador between expectation and reality of the web platform. A lot of times, they're like, “Well, what if we did this?” I'm like, “Okay, yeah. That looks cool, but let me tell you why this isn't accessible and why I strongly recommend going against this.” I feel like, yeah, as a part of the job as a UX developer, is having an understanding of the platform and where certain interactions are going to cause problems and being able to adequately educate stakeholders on what those problems are.

[00:17:24] T: Yeah. That's a question that I have a lot as well, is I've heard this saying that accessibility starts from the design, but I've never worked on an app where we have accessibility baked in. I'm curious to learn more about how it works when a company does build an accessible features, even though everybody throughout the process should be keeping an eye on it. How do you build that into the process? Then also in a more general sense, how would you define user needs? Because the user might not necessarily be wrong, but it's not the user's job to think of how to solve the problem. That's more on our end of things before we release the app. For example, if the user is like, “Oh, this note taking feature doesn't work like Excel.” I use Excel to take all my notes, make it more like Excel. Then probably, the next step isn't, “Okay, let's build Excel.” I think a lot of people, that response will probably sound familiar. I'd like to hear more about everybody's thoughts on that and how things work on your all’s teams.

[00:18:30] AC: I have strong feelings on this. I think, so many times we misidentify a customer's problem. A lot of that is the customer describes their problem one way, as in this example, it's not Excel and that's a problem for me, okay. The real problem is that you're unable to do some action that you would normally use Excel to do. What is that action? The problem is they can't do that action. We have the problem. Then solving that is the other half of that. It's how many different ways can we allow them to do this action? Does it actually address the core need? Because yeah, we could just add in Excel, but is that even the best way to solve their problem? Is there a more integrated way with the existing app to do it? Yeah. A lot of times, people conflate solution with problem.

[00:19:32] T: Speaking of conflation, I feel that's interesting as well, because maybe you only have one user who's like, “This should be working like Excel.” Then you identify the need, and it's not spread across a lot of users, so then you had to make a decision, like how big an impact will this make? Does it fit in with the goals that we're going for?

Then on the other side of that coin, that's an argument that I see and use a lot to be like, this is why we don't need to focus on accessibility. For people who have advocated successfully for accessibility, what have you used to counter that type of argument?

[00:20:07] JP: Yeah.

[00:20:08] T: That's probably makes better for everyone.

[00:20:11] JP: Yeah, it does. For sure, it does make it – Accessibility is marvelous and wonderful. I like to go back to a talk that I watched, I think a couple years ago. It might have even been this year before COVID.

[00:20:28] T: Who can really know? Might have been this morning.

[00:20:31] JP: Yeah. Yeah, it really could have, honestly. What is time now? Yeah. The person that was speaking was talking about how if you are trying to sell your application in all 50 states, and you are really excited about it and you're going to go to market literally next week. You as an accessibility person are like, “Cool. I love that idea, but what if it doesn't work in New York, the entire state of New York is not going to get your application?” They're like, “Well, New York has a lot of people in it and they're movers and shakers and there's a lot of really awesome people who live and work in New York and do cool things in New York.” You're like, “Yep, it's not going to work there. Don't worry about it.”

Your client is going to be like, “I need it to work in New York.” Okay, great. Awesome. That's what accessibility is, because the amount of people who benefit who are disabled in some way. Even if it's situational disability, or permanent disabilities, equals the amount of people who live in New York, which is a lot of people. To tell someone that just immediately saying like, “Hey, your application is not going to work in New York,” is almost – that clicks with people. Like, “Oh, wow. I would like for my application to work for everyone.” Great. We need to make it accessible. That's the rule on that now.

I think that has worked for me in the past, as well as just putting my foot down. Even if it's me against 50 other people, I will put my foot down. Because at the end of the day, making something more accessible, or starting, just even creating something new, a new feature, or a greenfield project, and making sure that accessibility is baked in, is going to help every developer who ever touches that code in the future. There's a lot less tech debt when you have accessibility at the beginning. You're not going to have that button problems, that's a 10-year-old button that's given exceptions for all the way down. You're not going to have that problem. It's just going to be a button. I mean, it really does help perfectly.

[00:22:44] AC: Yeah. Having created my own inaccessible mess previously, and I feel really bad for whatever it is. Currently on that project, well, it's, it's painful, it sucks. It is just so much better if you do it from the start. I have many regrets in that situation. Now, I'm not going to make that mistake twice. Yet, the way you said about putting your foot down, accessibility is a hill I will die on and I make that very clear, where I work. I was like, “I will die on this hill. If you want to fight me, okay. It will be to the death.”

[00:23:17] JP: My eyrie will a 100% come off for this.

[00:23:23] BH: I think what's challenging, I think what a lot of developers find with accessibility is, I think, another topic that I think receives similar problems, like performance talk of making your app as performant as possible, in the sense that I think we all know we want to deliver the smallest thing possible to the users, so you want to make everything the most accessible. I think most of us get lost in how to have those conversations. It seems like a binary thing. Our app is either a 100% accessible, or 0%, versus it's completely performant, versus not performant.

I think, when we're trying to implement change to organizations, where oftentimes, let's be honest, the stakeholders really just care at the end of the day, how much money things are bringing in. As a result, they make poor decisions that are often unethical, and that we often find questionable. I think in my experience, it's usually come down to learning to create infrastructure where people are doing things that are accessible without really realizing it.

For example, using libraries like Chakra UI is a great example of if you have your entire code base based on a project that is already has based components that are accessible and have them extend upon it, you've now reduced the barrier of entry of like, “Now I need to learn all of these things.” Don't worry, a specialist is taking care of it. You can start using it and growing your knowledge slowly. Also, just to Jenell’s point, one of the things we found really effective is if you can find the budget, hire. They have a bunch of consultants where have a blind user use your app, and then have that recorded. Obviously, they should be part of the consulting fee or whatever. Then have that play to your stakeholders.

Because I think, when we just say make things accessible, let's be honest, there's just so much noise these days that people will lose sense of what things mean and what to really prioritize. I think when people humanizing can see that interaction, that struggle of someone not being able to use their app, it becomes a much different priority, I think in their minds and I think, humanizing the experience can really make a difference in delivering that message to a group.

[00:25:14] JP: Absolutely. I definitely agree. I think one of the ways that I know that in my current job that I have had success in telling, “Hey, management or leadership, we need to work on accessibility,” is by using this pandemic as a driving point. A lot of people who are using our applications are working from home. When you're working from home, let's say that you are not physically disabled. You are a “normal user.” If you are working from home, you have children, you have to hold on to one child, and you are trying to go into the application and use the application while holding a child and being distracted. That is a situational disability. We are quite literally limiting so many people in this pandemic from using the application, just by the means of trying to take care of their children, or trying to be working individuals in their homes.

Just even watching someone who's a mother trying to use their application, like our application while focusing on their child as well is a huge thing. People will see that immediately be like, “Well, I don't want that,” right? This is a high-ranking individual who uses our application. If they are having issues with being in their home and using our application, that's an issue.

[00:26:48] T: Yeah. I feel that ties back nicely into Ben's performance comment as well, because a lot of people who are working from home don't have top-of-the-line Internet, and they're probably paying for it out of their own pockets. When we talk about performance, a lot of times those discussions can be coached in oh, the app is lagging a little bit for me on my superfast Internet, on super high-end computer. That means that it's already been causing probably a lot more severe lag on other computers and other Internet connections.

[00:27:17] JP: Yeah. Having a performant app is especially great for even other parts of making sure that everybody can use your application. People who are living in countries who don't necessarily have that resource. For example, I know that I have worked in Nicaragua before. In Nicaragua, have fun with your Internet, right? It's not a good vibe for you. To be able to use any application there would be super important to me as a developer, and to me as somebody who would potentially be living in Nicaragua.

Making the web accessible for everyone should be everyone's goal. That's how we learn. It's a human right to be able to use the Internet. I feel as developers, we need to make sure that all humans can use the web, period.

[00:28:15] T: Yeah. That brings me back to a point that Ben brought up earlier that I would like to add a little more nuance to. He was talking about how stakeholders, at the end of the day, they only care about money, so they're not going to care about the stuff we're talking about right now. I feel to me, at least, I think, or would hope that those are the stakeholders who only care about short-term gains. That in theory, if you build your app to be accessible and performant, and you really care about your end users, then over the long-term, you'll be more successful and more profitable.

[00:28:48] AC: I just want to share an example of a terrible attitude towards accessibility I came across recently. There's an open source JavaScript charting library called Plotly.js. Do not use it. I'm just going to start with that, because if for some reason you stop listening at this very second, that's the key takeaway here.

[00:29:09] T: We’ll make it the title of the episode.

[00:29:12] JP: Don’t use Plotly.

[00:29:14] AC: Plotly has an open ticket from May 24th, 2016, in which somebody is asking for the most basic keyboard accessibility of their charts. The response from one of the contributors was, ‘it is possible we could add these in the future, but I'm not sure whether we should be on very basic interactions. Plotly.js’s main focus is on plotting the data and exposing an interface to view it.’

The problem here is that you think that viewing it should be the only way that you can interact with it. Data is data is data. Giving users a way to interact with the data, when they can't see it, I get that this is data visualization, but data is still half of that.

Unfortunately, that is what my company currently uses. We are trying to move away from it, because yeah, I was heartbroken when I realized that we did not have an accessible charting library. Like, “No!” Yeah. Having that attitude that I only intended the user to be able to interact with it in this one way, then you're limiting it to not everyone. Also, I don't know if this, but I think something like, 20% of all Americans have some visual disability, whether it's just I need contacts to see well enough. If you happen to lose a contact that day. Yeah. Having the attitude that you only want to cater to a small portion of people is ridiculous and stop that.

[00:30:50] T: Yeah. I think also, just to tack on one really quick thing there. One interesting thing that I learned only maybe last year was that most blind people can see, which I think a lot of people don't know.

[00:31:02] JP: That is a really fun fact, to especially tell your stakeholders for sure. You should be like, “No, no, no. They can tell that you don't care. Don't worry about it. They can tell.”

[00:31:16] T: Yeah. I feel like, empathy and so called EQ, or now I'm like, is it emotional quotient? I've never actually looked at the acronyms, so I’m not sure.

[00:31:25] BH: I always said emotional quotient, but I might be wrong.

[00:31:29] T: You're going to say, but people have been telling me and I'm like, “What people?” I feel these are always on and off hot topics in tech. Do we need to care about the people side of things? Isn't it just about the code? What are people's thoughts on the importance of, or lack of importance of empathy and I guess, human qualities or “soft skills”?

[00:31:54] AC: A little bit of empathy should be evident, not only in your user interface, but also in your code. Empathy for the developer after you, empathy for yourself tomorrow, empathy for the person who ends up interacting with what you've built. I think that to be a truly great developer, empathy is the number one skill that you need to have. With that, I quit life. I’m just kidding.

[00:32:19] T: Ari is like, now you can really stop listening. Don't use Plotly. Empathy is important.

[00:32:26] JP: Mic drop. No, for sure.

[00:32:30] T: Make it your Twitter bio.

[00:32:33] JP: That totally makes sense. Yeah. I think, it should be our responsibility to make sure that everybody is – you have accessibility. Your code is accessible, that your application is accessible. I mean, beyond accessibility, just for ADA compliance, I mean, accessible to every human being. Because we want to make sure that we are being nice people.

At the end of the day, you want to feel you're invited to the table, to the party, to the whatever. Making your code accessible to anyone who comes after you, especially a junior developer, I think that's really important is making sure that your code is readable for an engineer to be able to look at your code and be like, “I get that. I see what's happening. I might not exactly know every step of what's happening, but I can generally understand what's going on and I can build on it, or remove it, or whatever it might be.” Without feeling extreme fear. I think that's super important. Because if you're coding for the junior developer that's going to pass and look at your code afterwards, that means that you're also coding for the senior developer who's looking at your code.

It goes for everybody. Anybody who might actually be looking at your code, because I know QA sometimes will be in there as well. Sometimes you have really cool technical product people, who look at code as well and want to know the deep ins and outs of why the features working the way that it is. Having your code be readable and having even just functions that make sense, that are human readable is going to help everyone, regardless. That applies to your code as well. If you have accessible code and accessible UI, your team wins all around, really. You don't have to explain yourself, which is also super amazing. No one's going to be like, “Hey, so Jenell, I looked at your code. It literally looks like trash.” Oh, [inaudible 00:34:43], which has never happened to me ever in my life.

[00:34:50] AC: For me, it's the smallest things that make a difference in the codebase. I don't know why my brain cannot get wrapped around this particular thing. Something I've seen in the codebase I work in right now is that instead of index, they say IDX. Even though I see it in a for loop, every time, I have to stop and be like, “What is IDX?” It takes me a full 20 seconds to be like, “Oh, index,” in the index part of the for loop. Yet still, lost on me. It's two extra letters, y'all.

[00:35:26] T: Yeah. I remember when I was learning JavaScript, IDX really threw me off. It was one of those things like, I see why am I in case you miss it, or OTOH, on the other hand, those are three acronyms I just never get, so I kept on practicing IDX, until it felt okay enough, but I don't think you should have to. For each, when they are like, well, the variable is right there. Each instance in the loop, I'm going to give it a single letter name and I'm like, “Don't do that.”

[00:35:53] AC: I hate those so much.

[00:35:54] BH: Nope. Nope.

[00:35:54] T: Why would you do that? What are you gaining?

[00:35:57] BH: I would rather have I, than IDX.

[00:35:59] AC: Same. Same.

[00:36:00] BH: If you’re going to review it, just go cut to the chase. One letter, done. We all know i. It’s great.

[00:36:06] AC: Yeah. No. The one letter in higher order functions, that drives me insane. I guess, maybe it's because I'm so used to being descriptive with whatever the argument is that I pass in. If I am working with an array of geez, okay. Say it's an array of colors. I am going to say, color, and use color as the argument I pass in, because I'm describing the singular object within that. Now, granted sometimes trying to come up with the right word for the singular of stuff they get it right, can be interesting. At that point, I will just go with element. It's generic, but I also get a full word. My brain cannot work with a single letter for something. It just can't.

[00:36:51] T: It's like, when people do ELM for element, and I'm like, “ELM, ELM.” The functional framework ELM? The tree ELM?

[00:36:59] AC: Or L? I hate that too.

[00:37:01] T: ELA.

[00:37:02] BH: Even if you pick [inaudible 00:37:03], if I’m like the element for the rapper –

[00:37:06] JP: Like EL wrapper?

[00:37:08] BH: EL wrapper. Because I've seen that a lot for signifying you have a DOM element, versus what – Basically, with jQuery, it was used to be the dollar sign, but now I've seen more people using just L as a prefix to basically, element button, element paragraph.

[00:37:21] T: Yeah. I think for me, it's mostly that that second E is taken out, because I seen LM and I don't love it, but at least it sounds like the thing. ELM does not.

[00:37:30] BH: I don't like ELM. Just EL. I've used EL before. That works for me, but I could see an argument for writing it out.

[00:37:37] JP: Initially, it was EL for me. I speak two languages, and so I immediately think ENT. Like the. I’m like, “Oh, the wrapper.” It makes sense.

[00:37:51] BH: Nice.

[00:37:53] JP: Which sounds cool. It’s the wrapper. It’s just fancy.

[00:37:55] AC: We just started using element UI at work. Every element is L card, L button. It's actually highly entertaining.

[00:38:07] JP: That makes me so happy. My best friend, when he first started learning Spanish a little bit. This was in high school, he stopped. He would just put O, at the end of everything. He would just be like, “Oh Carlito. Plantito and Doritoro.” I was like, “Yup, that's exactly where Doritos come from is from Dor, and then plantito at the end.”

[00:38:35] BH: The E at the Dor. That's what you're doing.

[00:38:37] JP: Obviously.

[00:38:39] BH: Obviously.

[00:38:40] T: Yeah. I will say, as far as reusable view component libraries go, I feel element stocks are pretty nice, compared to some others I've seen.

[00:38:49] BH: Then we use elements.

[00:38:50] T: As a side note. Yeah. I feel more realistically, when I'm writing code that I want to be readable at a glance, I'm writing for the me that's deep in the middle of trying to figure something out. Then I get 25 Slack messages. Then I had to go back to my code. The IDX for me is reduce. I ran into this the other day, where somebody was like, I was pairing, and they were like, “We could use a for loop.” Really, it would be better if we use reduce. I was like, “Better how?” Performance-wise, readability-wise. Why does it always have to be reduce? They're a very limited context in which I can understand at a glance what reduce is doing, but I feel there's a lot of really clever times to use reduce that a certain group of people are very proficient at, but I don't know that I would ever be in that group. I don't know how big that group is.

[00:39:44] JP: Yeah. I remember when I was first learning map and reduce. I literally had to tape them to my monitor, because I was like, don't know when to use them. I should, because everyone keeps asking me. That was always the worst. I should do that again, because I've been going back to like, I'm just going to use if and for. Need to go back to making better choices. Yeah, I get that.

[00:40:16] BH: I really wish they implemented a native shuffle array. Every time, I just want to be like, array.shuffle. Then I’m like, “Oh, no. I need Lodash. Or I need to copy from StackOverflow and make my own utility function.”

[00:40:27] JP: Lodash is like, secretly the MVP that you don't ever want to use. You’re like, who loves you so much lodash. Why do you have to be here?

[00:40:38] AC: Yeah. I avoid it. I avoid using it, unless absolutely necessary. Because yeah, I think, always aim for the simplest possible solution. If you're trying to be clever, you're doing it wrong.

[00:40:50] JP: That's fair. However, I know with interviews, they typically want you to be clever. I had an interview once where they asked, “Show me something. Teach me something.” I was like, “Okay.” I was like, this is the one cool thing I know. I showed it to them and they're like, “Yeah. Okay, that's cool. You could do it this way.” You'd be like, “Well, all right. We're just having a cool contest here.”

[00:41:23] T: Oh, my God. I'm going to say goodnight every time this happens from now on.

[00:41:29] AC: I think it's worth knowing other ways to do it. Because oftentimes, while one way of doing the same thing is more appropriate in one situation, there are times where in context, another way will make more sense. That context is just what is the style of the codebase you're working in? Are people using this particular built-in method everywhere? If so, that means people probably have a pretty solid understanding of it at your company.

[00:42:01] BH: Yes. Impact over being intelligent. That's what I like to say. I think as engineers, a lot of people like to feel intelligent, but don't realize the impact that it actually has. We need to focus on impact over intelligence.

[00:42:15] T: I think also, I don't remember if we said this, if I did this on the last episode, but I've been thinking a lot about how much recruiters – does this sound familiar, Ari? How much recruiters and hiring managers place emphasis on hiring the smartest and the best? I'm like, why isn't it enough to just be good enough at the job that they need you for?

[00:42:35] AC: Yeah. I think he did say something along those lines. I'm a goldfish, so –

[00:42:44] BH: For those who might not be familiar with the goldfish reference, refers to a short memory span, just in case you're not familiar.

[00:42:51] T: Oh, my gosh. I thought I was about to learn it was from some Pixar movie that I didn't watch or something and not just like I say.

[00:42:57] BH: Actually, In 1967.

[00:42:59] T: Ben!

[00:43:02] JP: I was just like, I'm going to smile and sit in this chair. Really good at smiling and sitting in this chair now.

[00:43:15] BH: All right, so as we close the episode, Jenell, where can people find you on the Internet?

[00:43:20] JP: You can find me on Twitter, because that’s where I live my life when I'm not coding. @nellarro. I have a website, but it's down right now, because I am the everyday developer who doesn't have time to update her portfolio

[00:43:42] AC: I never had one.

[00:43:44] BH: I think we [inaudible 00:43:45].

[00:43:45] JP: I love it. I might go to it. Yeah. If you want to see a just parked site, it's jenellpizarro.com.

[00:43:56] BH: Love it.

[00:43:57] T: Beautiful.

[00:44:02] BH: All right. Well, with that, it's time to move on to this week's pick. Ari, would you like to go first?

[00:44:09] AC: Sure. I have two picks this week. First one is The Crown on Netflix. I'm sure you've heard of it, blah, blah, blah. What's actually interesting about The Crown is that you can start any season without having seen the previous season and it will still mostly make sense. Because each season is a new era within Queen Elizabeth's reign. For example, between season two and three, it's a completely different actress playing her, because she's much older in season three. I actually totally skipped season two, just because I wanted to get to the Princess Diana stuff. I was like, “Oh, well. I should have maybe not start at four, but three is probably okay. I could have started on four and it would have been fine, too.” I watched all of season three in one day.

[00:44:58] BH: Wow.

[00:44:59] AC: It is highly bingeable.

[00:45:03] BH: The Crown's a historical documentary, right? Completely factual.

[00:45:07] AC: Yes. Well say, I'm sure they take some dramatic liberties. It is all very much based on real events. Each episode centers around a different historical event. Then how the royal family responded to it.

[00:45:25] BH: For those who didn't get my reference, there was a big hullabaloo about I think, the royal family trying to get Netflix to put fiction on the show, because they thought people would take it as basically, historical facts. That was my joke at that, so in case you didn't know. I realized. I was like, I should clarify this context I’m coming from. All right. It’s good to the Princess Diana season is what I'm hearing. I don't know if I want to commit to all those seasons.

[00:45:53] AC: That's where I was at. Yeah. You can totally skip. You may lose a little bit of context, but not enough that you will be completely lost and won't enjoy the show. The second pick is a video game, Hyrule Warriors: Age of Calamity.

[00:46:11] T: That’s I'm going to do on PTO.

[00:46:13] AC: It's fun. It's one of those just fun mindless things, but also has great Legends of Zelda lore. I mostly played it for the lore, but it's also just a fun game to play as well. That is my second pick and that's all –

[00:46:26] BH: That’s on Switch, I believe?

[00:46:28] AC: Yes, it is on Switch.

[00:46:30] BH: Nintendo Switch. Great. All right. Tessa, what do you got for us this week?

[00:46:35] T: I also have a Switch rec. Among Us just came out on switch two days ago and it's extremely buggy. Navigating with a real joystick, instead of a virtual one is a game changer. There's a glitch where you can explore their ridiculously large new map, if you're on Switch. You can join the game if you're not on Switch, but you can't see anything. My second pick, since you were talking about empathy, I had an interview once where the interviewers gave half the time to me to ask questions almost half the time, which is pretty new to me. It makes sense, because you're theoretically at least interviewing the company, as much as they're interviewing you, right?

They were asking me about a previous teaching job. They asked, how did I maintain work-life balance. I thought that was a really interesting question. Because usually, it's the candidate trying to think of a way to sneak that question in there to get an idea without somehow looking bad for reasons that I don't agree with, but I digress. That they were asking me that. I'm not saying, go out and ask your interviewees. A ways that for the sake of looking good, just look good. That they asked me that, showed me where their mindset was at. That really made an impact on me.

Yeah, I think just keeping in mind that it's not a one-way street in terms of interviews, but really living out that value, is I guess, one of my picks. Then my final pick, since we talked about empathy is I've been reading this book, Against Empathy by Paul Bloom, that I saw Tatiana Mac recommend a couple years ago, and I always meant to read it, and I'm just getting around to it now. It's talking about how in everyday discourse, we lump a bunch of words around being nice, or kind or compassionate into this bucket of empathy and this idea that you have to feel the way somebody else feels in order to understand their situation, or behave in a generous, or compassionate way, and the pitfalls that could lead to, whether it's, for example, with regards to donating to charities, or for example, with, I don't think this one came up in the book, but what I could think of is representation on in media. Like well, we can't have people from this demographic, because nobody watches. They won't be able to identify with that story. It's an interesting read. Those are my picks.

[00:49:02] BH: All right. Jenell, what do you have for us this week?

[00:49:04] JP: Okay, so I had a list. I'm going to maybe cut it down. First, I'd like to say that NK Jemisin is amazing. I've never heard of NK Jemisin, up until a couple weeks ago, and my lead was like, “Do you read?” I was like, “Yes.” She was like, “You know what? You should totally just try this person.” Looked her up and she writes amazing black fiction, specifically science fiction. It is so cool to see afro-futurism in book form. I am devouring these books. They're so cool, and they make me very happy. That is a pick for me.

Another pick, because we're doing – I'm going to piggyback off of Ari and do a Netflix thing. I want to say, Aunty Donna’s Big Ol’ House of Fun is amazing and hilarious. I've watched it quite literally four times in a row. It's super funny. It's just these Australian dude just having fun on Netflix. It's great. Just don't watch the second episode. The second episode is boring. Every other episode, fantastic and wonderful. Yeah.

I think, I put another one on here that I think I would like to talk about. Oh, and couchgames.tv. I wanted to shout that out, because that is my friend who wrote a bunch of four games that you would get typically, in those super niche shops, like Werewolf and other niche games. It is made with View and Beautify. It's super fun to play. The people who made the original game for all the games that are on coughgames.tv have actually been like, “This is awesome.” They've played games with him personally. I just think that is the coolest thing. It makes me super happy. I have more, but I'll just – maybe we could link them or something.

[00:51:21] BH: Yeah, absolutely. We'll make sure to include that in the show notes. Right. With that, I think it's down to me for picks. As far as that goes on the empathy conversation, for those looking to get more reading on this and this is a topic I know that we tend to shy away from, but there's a book called Difficult Conversations. That one, it's a little bit more academic heavier read, but it does go into the nuances of the kinds of conversations we often avoid and call it strategies and ways to process and deal with them and approach them. If you're interested in that, be sure to check that out.

As far as fun picks go, for those you can't see, but Tessa's waving her Difficult Conversations book at me, which is very nice, very nice. My fun pick is a game that's on Steam. It's a little bit old, but it's called The Escapists 2. The premise is pretty nice. Basically, it’s an 8-bit game, and you and your friends are in prison and you basically have to find ways to break out. You'd accomplish little quests together, or you're finally to dig holes and stuff, or the wire, and it's a pretty fun co-op game. If you’re looking for something fun to do with friends, be sure to check that out. It works on both Mac and PC. I mean, that's a big win, whenever I can find a steam game that can work on both platforms.

With that, that is all for this week's episode. Thank you everyone for listening. Until next time, enjoy the vue.

[END]