We Are All Hemingway

So Hey everyone, welcome to the We're All Hemingway talk. My name is Krasimir Tsonev 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 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. I started by listening to non-fiction books and then I moved to more fiction books. At some point, being an author myself, I was thinking why not my fourth book to be a fiction book? Because so far I was writing only technical books, so I was thinking why not try something else. I think this is a project, so I decided 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. I decided to watch a tutorial about it. In this case, it was more of listening to other books, which are books about how to write a book. I find them really useful and started pulling out some quotes, some tips from there. 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 tips for programmers. 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. Probably all these people that write amazing fiction books, they have something to teach us. Roughly at this time, I watched a talk by Jane Creighton at React Conf 2019 called React is Fiction. I was like, oh, shit, it's not only me. There are some other people which noticed the same thing. Today, I decided to share with you the most important tips which I found. I hope you'll find them useful as well. 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. Here's what Hemingway said. Write about what you know. Know. This may sound really simple thing, but I found that it works really well. At least it works for me. Let's take an example. Let's say that we have this component. We have to write this fetch 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 we render when the data is loading. Maybe fallback is not the right naming, to be honest. Then we have the data passed out of the component. Now, if you don't have experience writing React applications, maybe we know something about React, but not really a lot. If you follow this advice about what you know, you can just start by rendering the fallback. This is the really basic thing with React, just about rendering something. We just render the fallback. This is our first step. Then, if we start reading the documentation, we'll see this thing called your states, which is the basic building block about local state management. We'll just reserve a place for the data. If the data is there, we call the children, which we expect to be a function. Otherwise, we just render the fallback component. At this point, we already have enough, so we could start asking more questions. 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. If you have nothing, you don't even know what to ask, actually. 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 is a hook use effect. 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, especially when I start something new. I write what I know, and then I build on top of it. This really puts you in a position of asking questions, which is a really good place to start with. 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 be conscious about what's happening in the book. We can talk a lot about complexity in software development, especially in our JavaScript ecosystem. 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. To be honest, if you're going to take something from this presentation, I want it 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. 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? This is a powerful question to ask, especially when you have your first draft of something. Then you should really ask yourself, is this part of the story? If you continue with the same fetch component, let's say that we have to handle the error, for example. There's no error handling. We receive another task about, hey, we have to make sure that if there's an error, the app is just not crashing. We have to render a message to the screen in case of HTTP request failure. We write what we know. We just reserve some space for the error using another local state. We attach a catch message handler at the end of the promise chain. If there's any error, we just store the error in the local state. Then we have to show the message. We have to render the message to the user. We could check if the error is not null. If it's not null, we just render this message. Here's the moment where we have to ask, is this part of the story? 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 maybe 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. 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. 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're at this stage where you start asking more questions, 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 if you 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. How can you get more experience? Hemingway said when I was writing, it was necessary for me to read. 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. What I'm talking about is you should try reading code of other developers. I, for example, and I'm pretty sure the same as you, you probably write this piece of code many times. This is how we connect a component or a Redux store. Back in the day, I was wondering how this connect function works. When I opened the code of React Redux library, this screenshot is close to what we have now. I guess previously was kind of the same. We see a function that accepts our component. Then inside, there is another component which renders our original component. 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 articles about it. I gave this thing a name. Then I think I even released a library which was doing it. When I share it across the web, people are like, this is like a harder component. It's not a new thing. People use it for years. So, I was again reinventing the wheel for myself, but it was really interesting to find out how everything works 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 that's right at work, but just the code of libraries. Don't be afraid to jump into a big code base like the React ones, for example. If you just step by step reading how everything is organised, you probably learn a lot. There is another pattern which I really like, and this is the function as child component pattern. This is an example of Formic, but I think the first place where I saw this pattern was kind of the React library. 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. Okay, 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, it was a bit weird, but children could be really anything. It could be even a string or a number. It doesn't matter to React. This pattern specifically is, to be honest, my favourite one because it gives some responsibility to the component, like in this case Formic, but at the same time, it's 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? 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 kind of 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 to even to make the code review. If someone spends like an hour reviewing your 50 lines changes, it means that it's not really good. 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 getEmail. We have an input field, 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. In this case, I know that this component is registering a user. It's not about getting the user from, getting the email from the input field only. It's about registering the user, 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 what this function, 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 implementation. So, this is my approach. Initially, I start from the outside. I look at the API, and I usually just rename stuff. Sometimes, I found props which are not, which shouldn't be there. They're not part of the story, for example. And when you move forward, inside the value is actually an email, so why not just call it an email? It will be easier for 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. Even now, we can see that this has a potential bug, because if this fails, the app will blow up. Here's again, this is my favorite question. What's the story here? The story here is about making a request and handling the error. We could just write two functions, and it's much cleaner, I think. And we are even fixing the bug, because if the second request fails, we'll still be in a trackage block. All this refactoring is really about, I guess it's about Miasville, because after a week of time, I probably don't remember what's happening. But in general, it's just for other people. We should write 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 handle, and this is the link for the slides. Yeah, thanks.