We Are All Hemingway

♪ Hey everyone, welcome to the Wear All Hemi Great Talk. My name is Krasimir Tzonev and I work for a company called Antidote. We help patients reaching clinical trials and we use React in all of our front-end apps. When I'm not working, I'm pretty much spending time with my family. We have two kids so I have to drive them around a bit for school and kindergarten. I can't cook at home so my wife is cooking. I'm doing the dishes. I used to run before. I'm not running that much recently, but I used to run before. And during all these three activities, I was actually listening to audiobooks. That's how I keep my brain working. And I started by listening to non-fiction books and then I moved to fiction books. And at some point, being an author myself, I was thinking why not make my fourth book a fiction book. So far I was writing only technical books, so I was thinking why not try something else. And I take this as a project, so I started to approach this as I'm approaching all the other my projects, basically checking how to do it, because I don't have experience writing fiction. So I decided to kind of watch a tutorial about it, like in this case it was more of listening to other books, which are books about how to write a book. And I find them really useful and started pulling out some quotes, some tips from there. And when I have this kind of a big list, I was going through the list and I realized that actually, most of these tips were working for software development as well. It wasn't just about writing fiction, for example. Some of these advices were actually really good for programmers. And if you look at the date of the first novel and the date of the first program, we see that there is this huge gap. So probably all these people that write amazing fiction books, they have something to teach us. And roughly at this time, I watched a talk by Jane Creighton at React Conf 2019 called React is Fiction and I was like, oh shit, it's not only me. There are some other people which noticed the same thing. So today I decided to share with you the most important tips which I found. And I hope you'll find them useful as well.

So the first thing which I believe most of writers of fiction actually face up is the blank page syndrome when you stare at the blank page and you don't know how to start or you don't know how to continue writing. We have the same thing in programming as well, especially when you join a new team or you just open a new code base or you are maybe more of a junior, you don't really know how to start writing something. And here's what Hemingway say, write about what you know. And this may sound really simple thing, but I found that it works really well, at least it works for me.

So let's take an example. Let's say that we have this component and we have to write this fetching component, it doesn't exist, we just receive this as a task. We know what the API should be, the component should accept URL prop, should have a fallback, which is a component that render when the data is folding. Maybe fallback is not the right naming to be honest, but... then we have the data passed out of the component. So, now if you don't have experience writing React applications, maybe we know something about React but not really a lot. So, if you follow this advice about what you know, you can just start by just rendering the fallback. This is the really basic thing with React, just about rendering something. So we just render the fallback. This is our first step. Then, probably if we start reading the documentation, we'll see this thing called your states, which is like the basic building block about local state management, and we will just reserve a place for the data. If the data is there, we code the children, which we expect to be a function. Otherwise, we just render the fallback components. And at this point, we already have enough, so we could start asking more questions. And I found out that this is a really important stage where you have something to rely on, and then you build on top of it, because if you have nothing, you even know what to ask, actually. So the next step will be to probably ask someone more experienced about how to handle asynchronous operations, how to make HTTP requests, or maybe you just continue reading the documentation, you'll probably find out this hook use effect. And then you place inside the actual request, you get the data, and you send it out using the children function. So this is the first thing which I found useful is when I especially when I start something new, I write what I know, and then I build on top of it. And this really puts you in a position of, of asking questions, which is a really good place to start to do it.

Then when you start knowing stuff, it comes the complexity. When I was listening to all these books, I actually found out that there are complex books as well, the complexity is not only in software. I listened to some books which were, they have many plot lines, they have many characters, a lot of connections between the characters, there are some flashbacks. So I have to be really listening. For example, when I was running, it was difficult to listen to such complex books because I have to really be conscious about what's happening in the book. And we can talk a lot about complexity in software development, especially in our JavaScript ecosystem. And here is what Stephen King says about writing.

When you're writing a story, you're telling yourself a story. When you're rewriting, you're taking out all the things that are not a story. And, to be honest, if you're going to take something from this presentation, I want to be this last sentence. What I'm making from this quote is that we should be taking out all the stuff which are not part of the story. And the question which I'm asking myself all the time is, is this part of the story? Every time when I'm writing a component or a function or whatever, I'm always asking myself, is this part of the story? And this is so powerful question to ask. Especially when you have your first, your first draft of something, then you should really asking yourself, is this part of the story? And if we continue with the same fetch component, let's say that we have to handle the error, for example, there's no error handling. And we receive another task about, Hey, we have to make sure that if there's an error, the app is just not crashing. And we have to render a message to the screen in case of HTTP request failure. So, we write what we know. So, we just reserve some space for the error using another local state. And we attach a catch in the end of the promise chain. So, if there's any error, we just store the error in the local state. And then, we have to show the message. We have to render the message to the user. And we could, I mean, we could check if the error is not null. If it's not null, we just render this message. And here's the moment where we have to ask, is this part of the story? And to be honest, this message is not part of the story of this component. Because this component is just about fetching data. It's not about copy. It's not about styling. It's just about getting the data or handling the error, if there's any. This is definitely not part of the story of this component. It's probably part of the story of the component which is consuming fetch. So what we can do is to check if there's any error. If there's any error, we could send the error as the first argument of the children. I mean, this is just my choice, but it could be any other signature. By doing this all the time, by asking yourself is this part of the story, you're basically writing simpler components. At least that's my experience. Then when you are at this stage where you start asking more questions, and to be honest, I think you can clearly see the difference between a more junior person than a middle level person when they start asking questions. If you start asking the right questions and especially start answering these questions, then you can talk about seniority.

Asking questions all the time is really a good approach to find better solutions. The problem is when you don't have enough experience, you don't know what questions to ask. So how can you get more experience? Well, Hemingway said when I was writing, it was necessary for me to read and Stephen King has another quote about if you don't have time to read, you don't have time to write. I'm pretty sure that reading a lot of code, especially for your colleagues or for your code base because you have to do pull request reviews for example. But what I'm talking about is that you should try reading code of other developers.

I, for example, and I'm pretty sure same as you, you probably write this piece of code many times. And this is the way of how we connect a component or Red Hook store. And back in the day, I was wondering how this connect function works. And when I opened the code of React Red Hook's library, so this screenshot is close to what we have now. I guess previously was kind of the same. But we see a function that accepts our component and then inside, there is another component which renders our original component. So I started playing with this pattern and I was so I mean it was so interesting to me how everything works. Then I started writing article about it. I gave this thing a name. Then I even released a library which was doing it. And when I share it across the web, people are like, this is like a hardware component. It's not a new thing. People use it for years. So I was again reinventing the wheel for myself. It was really interesting to find out how everything was just by reading the code. I can tell you how many things I learned just by reading the code of others. Not just the code at work, but just the code of libraries. And don't be afraid to to jump into a big code base, like the React ones for example. Even just step by step reading how everything is organized, you will learn a lot.

There is another pattern which I really like. And this is the function-as-child component pattern. So this is an example of Formic. But I think the first place where I saw this pattern was kind of the React Router Library. And here, if you don't know how this works, we could just jump to the Formic Library and see how there is this component Formic. Oh, they read the children from the props. OK, so this is the native React prop. Oh, and they just call the children as a function, which for the first time when I saw it was a little bit weird. But children could be really anything. Could be even a string or a number. It doesn't matter to React. So this pattern specifically is, to be honest, it's my favorite one because it gives some responsibility to the component, like in this case Formic, but at the same time is able to provide something out of it, like in the consumer of the component. So read the code of others, especially all these really popular libraries, because usually these projects, they're a cooperation between a lot of developers, and I'm pretty sure that they're, collectively, they made something really smart and they took really good and interesting decisions. So if you have a chance, just check some of these libraries.

So, the last part of my presentation is really a question. Again, I'm going back to the point where you have to ask questions all the time. So my top question usually is, who is the reader? And when we are writing fiction books, I guess this question is kind of debatable, I guess, for writers fiction, but for software developers, I think it's really clear that the code that we are writing is not just for us. It's mainly for other people to consume it, to read it, to maintain it, to extend it. So, it's important to write for others, for other people. And here's what Stephen King said, write with the door closed, rewrite with the door open. I'm always remembering this quote when I'm going through my pull requests before announcing it to my colleagues, because even Hemingway said that the very first draft is always shit, I'm quoting, but then after that, you have to go back, you have to ask, is this part of the story all the time? So, you have to write it in a way that it's simple for other people to understand, it's simple for other people even to make the code review. If someone spends like an hour reviewing your 50 lines of changes, it means that it's not really good. So, if you take this example, for now, don't focus on this area, the action prop of the form component. Let's say that this is a component about, it's called get email, we have an input field called we type email. When we change something, we store the value into a local state called value. And we have a button submit, which probably, if we press it, we go into the action of the form component and we register the user by using the email. So now, this I consider a draft. And I could make a couple of improvements. The way of how I refactor my components is first to look at the components from the outside, like the API, which means the name of the component and the props. And in this case, I know that this component is registering the user. It's not about getting the user from getting the email from the input field only. It's about really registering the users, so we better just name it register. We have a prop called callback. For sure callback is a function, but it doesn't really talk about why this function is fired later. So onSuccess, I guess, is better. Error doesn't even work like a function. So we have no idea from the outside that we have to provide a function, so we better call it onError. By doing these small changes, even though it's just renaming, we help other people understand better our component, even without going inside the implementation. This is my approach. Initially, I start from the outside, I look at the API, and I usually just rename stuff. Sometimes I've found props which shouldn't be there. They are not part of the story, for example. When you move forward, inside, the value is actually an email, so why not just call it an email? It would be easier when you're reading the file from top to bottom, and when you hit the email, you just actually see that this is an email. And now, this piece of logic, which is about making the requests using this API.users.register, if this fails, then we check the type of the error.

If it's something on the server, we retry. And even now we can see that this has a potential bug, because if this fails, the app will blow up. And here's, again, my favorite question, what's the story here? And the story here is about making a request and handling the error. And we could just write two functions, and it's much cleaner, I think, and we're even fixing the bug, because if the second request fails, we'll still be in a try-catch bug.

So all this refactoring is really about, I guess it's about Measville, because after a week of time, I probably don't remember what's happening. But in general, it's just for other people. So we should try the code for other teammates, for other people, which we don't even know in the ecosystem.

And with this, I want to kind of finish my presentation. If you like some of the tips that I mentioned, I strongly recommend checking these books because I listen to them. And maybe you'll find something interesting as well. Thank you for watching, for listening. This is my Twitter handler, and this is the link for the slides.