A talk focused on how lots of frontend technologies are more difficult to pick up than people claim and how we can learn to teach with empathy.
This post contains the video and a full transcript of the talk.
Presented on September 27, 2019 at React India.
Hi everyone! Wow, there's a lot of people here. I'm excited.
Alright, so as Mariia mentioned my name is Carolyn and I'm a frontend developer based in Berlin, Germany. This is my first time in India so I'm really excited to be here. Back in Germany, I'm working at a company called Blacklane and I'm also a Mozilla Tech Speaker - but before all of that, I used to be a technical writer. So I've always been interested in how we learn new technologies and, perhaps more importantly, how we're teaching those technologies to newcomers. And that's kind of what led me to this topic of "intuitive" tooling.
But before we get started, I want to clarify something. When I say tooling, I'm using it like very, very, very generally. For the purpose of this talk, tooling will encompass all of the things that are related to our code that are supposed to enhance our own developer experiences on the frontend. So think like type systems, state management libraries, static site generators, etc.
So sometimes I get really overwhelmed by all of the tooling that's both available and frequently talked about within the frontend community. Earlier this year, when I was feeling particularly down about all of the technologies that I don't know and I probably will never know... Yeah, I was feeling really down about it and like any time that I feel slightly inadequate - I turned to Twitter for validation.
And I asked frontend developers what are some tools, technologies and buzzwords that people describe as "simple" or "easy to pick up" but they still just... don't get. And I found out that I wasn't alone. Hundreds of people replied or privately messaged me to tell me about all of the things that they're struggling with and for the first part of this talk, I want to touch on the five most frequent answers that I received.
Fair warning, I'll be talking about these from the perspective of my personal experience so your experiences with these technologies perhaps - and probably are - really different. And spoiler: I won't be talking about webpack even though that was probably the most frequent answer. Frankly because I think people who say that webpack is easy are the same people who say they don't talk shit about their past employers aka they're liars.
Anyway, okay, I want to start off with Typescript because selfishly this is what I've been struggling with at work recently. According to the website, Typescript is a "typed superset of JavaScript that compiles to plain JavaScript." When I was confused by reading this, people just told me that it's like "just some types on your JavaScript" or a lot of people told me "it's just like Flow but better" - but like, both of these aren't really that helpful of descriptions.
I would argue that Typescript is a whole new language. Maybe if you already know a strong, explicit, statically typed programming language then it's less of a stretch - but if you're only familiar with JavaScript then it is pretty different than what you might be used to working with. It has its own compiler... Not to mention things like import * as React from 'react' or vague errors that happen because the documentation never mentions that an empty array without a type annotation is automatically type never so you have to dig through like every single issue response on the repo itself. And finally, there are just like way too many, in my opinion, way too many file extensions like *.tsx *.d.ts *.map *.js - it's a lot.
Alright, next I want to take a beat and talk about Redux - described on their docs as "a predictable state container for JavaScript apps." And when I was first learning, I literally googled the phrase 'why is Redux so confusing' and there was actually a Quora topic with the exact same title. So naturally, I clicked on it and the first advice that was listed in this like question answer thing was "I think the best way to learn Redux is forget trying to understand it." After that, I asked one of my colleagues who was kind of like the cheerleader behind Redux on our team and he sent me the Elm architecture documentation because he thought it would be a 'good foundation for my learning.' And I know he meant really well, he's very sweet, but that has to be an indicator that it's not that simple.
There are also some concepts in Redux that take a bit of getting used to - like how unidirectional flow works. You'll have to navigate your way through a lot of jargon like action, async action, action creator, store creator, store enhancer - like you get my point, they all sound the same. Fortunately, the Redux docs team is really dedicated to improving the developer experience so there's now a glossary for all these terms, but still. And finally, there's a lot of middleware that I think makes it especially confusing, particularly thunks and saga or really anything asynchronous - it's just also a lot.
Moving on, GraphQL. So I actually have an entire talk dedicated to how I think GraphQL is really difficult to learn so I won't spend too much time on this one, but I want to talk about it. When I talk to people about GraphQL, I hear a lot of things like "I use it but I don't get it" or "I feel like I know it but I also know that I don't." And this is understandable especially when you're first learning and people say things to you like "it's kind of like JSON" - but not really. "It's kind of like types" - but not really. "It's kind of like string interpolation" - but not really.
And okay I'm done, but like it's a difficult concept to wrap up in one sentence and also I find the name even confusing. Like particularly the graph part of GraphQL. When I first heard about GraphQL, I figured it was like D3 or maybe another programming language that makes charts. Spoiler alert: It's not. But it's not the most ridiculous conclusion to draw if those are the only graphs that you know.
Speaking of GraphQL, let's talk about Gatsby. So Gatsby always gets a lot of love during React conferences and generally I've heard people describe it as the "easiest way to make a static website in React"... I don't think so, but now I'll give Gatsby credit. It is beginner-friendly... if you already feel proficient and comfortable with React or if you understand and can use GraphQL. Or if you want to build something that's relatively small, maybe templated, and not super custom. But even that doesn't guarantee you success.
Gatsby has a lot of magic under the hood that no one seems to be sure about or can confidently explain. But luckily if you get stuck on something you can just delete the cache folder. I'm just kidding, but it can actually fix a lot of issues if you're running into them. Like many technologies I've mentioned, the Gatsby team does care deeply. They even have a learning team and they put a lot of effort into improving their error messages and documentation - which at least, I really appreciate.
So the last of the top five answers I received was Flexbox - or some combination of, you know, Flexbox, Grid or just general CSS. And all I can say is... that I get it. Like pretty much every time I have a ticket that involves Flexbox, I immediately go through all 24 levels of Flexbox Froggy. Okay but can you blame me? It's kind of like Redux - all of the property names sound the same. You have align-items, you have align-content, justify-content, flex-wrap, flex-flow, flex-direction. And if you're like me and you never properly learn all of these, all this terminology - you're probably very familiar with this page, which is the complete - everyone's laughing but it's true - the complete guide to flexbox by CSS Tricks. Apparently, rumor has it, that this page actually has more views than the home page of CSS Tricks. You're not alone, don't worry.
And okay, I know I said that I would talk about five but because we're at a React conference I need to add that I personally don't think React is as intuitive as everyone kind of claims it to be. Between component lifecycles and JSX - let's say that it was a further stretch from the vanilla JavaScript that I was familiar with and that I expected and there were a lot of tears, mostly from me, during my bootcamp when they introduced React.
So honestly, my original plan for this talk was to just like keep going like this for another 20 minutes. Just like rant about all the technologies that I don't know or that I find confusing. But then I thought about it and, I don't know, I don't think it would be really fair to our community because this issue is far bigger than frontend tooling in the React community. It's actually tech in general.
My very first job in the tech industry was to create materials that would basically explain blockchain to artists. And my bosses always seemed really confused that we had to keep continually iterating over the core concepts of blockchain. And me, as a non-technical person at the time, I was equally confused by their confusion. Like blockchain, at the time, was still fairly new and overall I don't know if I would ever use the term "simple" to describe blockchain.
So fast-forward a few years and I'm watching a talk online by Jim Fisher titled 'Don't say simply' from the Write the Docs London meetup. Towards the end, he discusses why we do it - why we continually use this word even if it's not necessarily appropriate for the situation. And he makes a very important distinction that, for me at least, put it all into perspective: We mistake familiarity for simplicity.
And seriously, like he said this and I was like oh my god the stars have aligned, like my mind is blown, everything is amazing. We mistake familiarity for simplicity.
Now, when Jim talks about it, he talks about it in the context of technical writing. So you work for hours and hours, week after week, to build this product and you become super familiar with it - to the point that you don't even cognitively recognize those core concepts as you work with them. And then we forget that those concepts aren't necessarily universal. So naturally, when you go to document the product, you forget to kind of take that step back and get that perspective.
And I think the same logic can apply to technologies that we learn. Think about how much time you dedicate to, you know, working through a React course or reading a Typescript tutorial - and that's before you even dive into the codebase that you're learning it for. Then think about all of the hours, once you get into that codebase, that you spend frustrated over vague errors and failing tests. But then once you finally make it through and you start to feel really confident - it's like oh yeah this is simple.
Another thought I had throughout this experience of tweeting and receiving a bunch of responses was like wow okay if so many people feel the same way, about a lot of the same technologies, why aren't we talking about this more often?
Okay, at the risk of sounding like I'm doing some like school presentation, there's a political and mass communication theory that describes this very well. It's called the Spiral of Silence and it proposes that people have a fear of isolation. And this fear of isolation comes from the idea that the social group that they're part of might isolate, neglect or exclude members if they voice certain opinions. So they don't, they stay silent.
And I see this a lot in our industry and I can even feel myself doing it fairly frequently. So I'll scroll past like a conversation on Twitter where people are talking about onboarding a new colleague to a React/Redux project and someone will reply like 'oh why do you even need an onboarding? Just give them an afternoon and a link to the docs and then they'll be totally fine' - and all of me wants to say something. You know, defend onboarding and how important it is. But I won't and I know many others who probably wouldn't either.
But the thing with the Spiral of Silence though is that there's an important point to it: "The assessment of one's social environment may not always correlate with the reality." And I believe that this is the case for many of us working in tech. So how can we bridge that gap between our perceived reality and our own lived experiences?
I think the answer is empathy. And okay, before you roll your eyes, let me explain. So empathy is a cool thing and it's especially a cool thing to leverage because it's naturally hardwired into our brains. While yes, I think we should all be a bit more aware that the people around us are like whole humans - this isn't what this is necessarily about. I'm calling for increased empathy, sure, but I want to focus on how we can translate that empathy into action. And that way, we can become better teachers for those that we work with and as well as better mentors within this community that we're in.
This is because empathy matters more in educational contexts. In our case as developers, this is primarily like training new colleagues as they learn the required skills for the job. And studies show that these folks will learn faster, better and last longer if empathy is what is driving that learning. But the thing is, empathy also requires humility - which isn't always like... the most abundant quality in our industry. By having to truly see the world the way someone else does, you have to acknowledge that your perspective isn't the only one. So if something was easy for you to learn, that's great, that's amazing - but it's not always going to be the case for someone else.
There are concrete steps that you can take to cultivate empathy if it doesn't come naturally to you. I won't dive into these now, although I'm happy to discuss it later - but I do want to give you some suggestions for creating more productive and supportive spaces, maybe at work.
So we can start by taking ownership of the communities that were already involved in. Particularly, we can foster supportive spaces within the organizations we work in - one that gives people confidence to combat that Spiral of Silence I mentioned earlier.
I always think about how awkwardly I feel when I'm doing any sort of like dance related exercise course. For context, I can't dance. I mean, I will dance but I'm not very good at it. I have no rhythm. And I might feel totally like I'm in shape and I can do a group workout together, but add one element where I don't feel very confident or that the steps are new - and it instantly becomes hard and potentially demoralizing. And I feel very similar also when I'm coding.
And it feels like this because when you're learning something new and you're struggling - having emotions is pretty inevitable. And these emotions that you're getting when you're struggling live in the most primitive parts of our brains and it makes it significantly more difficult to rationally assess our own situations. So there's a lot of comfort in acknowledging these emotions because it helps calm that primitive part of our brain and allows our rational brain to see the situation a little differently.
That's why when we're in environments that are caring and respectful and positive and there's people around you saying like 'yeah you can do it, no worries, we all screw up, here's the next step' - all of a sudden, learning is exciting and fun and we want to keep going.
Another thing that I found especially helpful at my current company, Blacklane, was that we started an internal mentorship program last summer. Every engineer, everyone in engineering, was paired with a mentor and you have regular one-on-ones with this person. And ideally, this person should be someone whose work that you admire. It doesn't mean that you have to work with the same technology. Mine, for instance, is a backend developer while I primarily work on the frontend.
It might be someone that you're already having these kind of candid conversations with or that you'd be open to doing so. And, I cannot emphasize this enough, it should not be your direct line manager. What I found personally is that by having these one-on-ones be kind of a safe space for me where I'm able, and even encouraged to, let out my feelings without judgement - it helps me stay in control while I'm at work and not be consumed by any potentially harmful thoughts.
Alright so maybe what I just said sounds nice but it's not necessarily something that you can use tomorrow or next week or I don't know whenever you all are going back to work. So I wanted to give you a few more pragmatic ideas.
Even if you're not a formal mentor, we can all practice teaching with empathy. As I mentioned earlier, learning more complex things often comes with this emotional component. And many of us, when people come to us with these emotions, we tend to brush it off and immediately focus on providing solutions. What we miss is that the person who came to us might be looking for empathy and validation just as much as solutions.
We can provide this for people by relating back to our own experiences. And if you're not sure how to do this, you can use the feel, felt, found structure. Start with "I can see that you feel..." and acknowledge their frustrations, emotions or whatever seems to be going on. "I have felt that way when..." and give a concrete example. It doesn't have to be the same technology or even the same feeling necessarily, just something that you can correlate to an actionable takeaway. Using "What I have found is that..." and offer them something. Maybe it's a resource or a learning tactic, validation - your choice, like whatever you see fit for the situation.
What we can also do is ban isolating words like easy, simple, obviously from our everyday vocabulary. This is already a common practice in technical writing but it hasn't really expanded past documentation yet. But we can learn a lot from these practices and learn to be more mindful of the word choice that we're using. If you're struggling to find alternatives, Jim Fisher who I mentioned earlier has some suggestions for us. You can be more specific. So maybe a particular static site generator is easy because it's quick to set up or doesn't require much custom configuration. Jim says that if that's the case, we should say so.
Or you can be comparative. Something is smaller than something else. Your state management alternative requires less middleware for async functions than Redux. Or your CSS solution has fewer property names to learn than Flexbox. You can also be absolute. So it takes five lines of code to integrate this with your project. Here's a link to a specific tutorial that helped me understand this.
When you suggest being absolute, a lot of people immediately jump to time as a marker. To show how easy something is, you might have seen a lot of, they're usually marketing videos, that are like 'launch a website in less than 10 minutes' or 'build your own server in 30 second' like whatever. And in this case, it would be recommended to show and not tell. If you really think it takes five minutes to add a certain template to your static pages, I would challenge you to make a video and try doing it yourself. And also remember that keep in mind but if it takes five minutes for you, as someone who's maybe familiar with the technologies, it will take longer for someone who is brand new to the project.
When you do think something is easy, what we can also do is take a moment to deconstruct why we think it's easy or why you found it easy to pick up when you were learning. So if we take our Gatsby example from the beginning of this talk - maybe when you were learning Gatsby, you already had a solid foundation of React and GraphQL. But the person that you're speaking to doesn't. This can help you recognize those gaps and can help you determine what to recommend next to that person.
And finally, you can keep a journal while you're learning something new. It doesn't have to be anything super deep - like write paragraphs per day - but even just jotting down a weekly bulleted list of one thing you learned, one thing that you struggled with and any helpful resources you discovered. Then when you're teaching someone new, you can refer to that list and either use that to cultivate that empathy or maybe suggest some resources for their learning.
Alright, so hopefully I've given you at least something that you can use when you leave this conference and want to implement all of the cool technologies you hear about the next couple days. But I'll just leave you with some final thoughts.
So just because you understand something doesn't mean that everyone else will. People learn at different rates and this applies for all facets of life, like not just programming. For example, I can hardboil an egg but I have no clue how to fry one and I've pretty much failed every time I've tried to fry an egg even if most people tell me like 'oh it's really easy.' But for Sara Vieira - who was one of our speakers who unfortunately couldn't make it but I couldn't find anyone else for this metaphor - it's the opposite. She can fry an egg but she can't necessarily boil one even though I find it easy to boil an egg.
Brains are weird. But seriously, whether it's eggs or JavaScript frameworks, what you need to remember is that no matter how intuitive you think your tool is or how advanced you assume your users might be - everyone starts somewhere and everyone is a beginner at some point in time.
And I feel like I need to mention that it's okay if things are hard. Like I would argue that programming is hard, I think it's very hard. But chances are that you're probably doing alright.
Before I leave the stage, I wanted to end with one quote from Jo Frank that sums up the past 30 minutes or so in two sentences. In one of her talks, she said that: "By saying something is easy, you remove the accomplishment of learning something as it was always supposed to be easy. And learning something is always an accomplishment."
Did you find this helpful or useful? If yes, please consider buying me a coffee so I can continue to give talks like this ☕️
Top comments (2)
I’m glad I saw you present this talk live at React India. The point I liked the most was - “We mistake familiarity for simplicity.”
Jim Fisher is a genius! Thanks for the shout, I'm glad you enjoyed it 😁