Video details

We Are All Hemingway | Krasimir Tsonev


Krasimir Tsonev

Do you know that the first novel ever written dates back in 1021. Its author is the Japan noblewoman Murasaki Shikibu. Till then countless of writers put their thoughts on paper and countless of readers experience their stories. People write for decades and we, as software developers, kind of ignore their craft. We write too. Not novels but software. Isn't it this still writing? Believe it or not there is a lot in common between creating fiction and writing code. In this presentation we will see how close we are to giants like Hemingway and Stephen King. Can we get some of their wisdom and apply it to our daily job as engineers. Come to this talk and will get a few practical advices. I hope my presentation will make you a slightly better React developer.


Hey, everyone, welcome to the where our Hemingway talk. My name is Krasimir Tsonev and I work for our company Quantitate. We help patients rich in clinical trials and we just react in all of our products. 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 from 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 I was actually listening to audiobooks. That's how I get my brain working. And I started by listening nonfiction books. And then I moved to more like a fiction books. And at some point, I 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? And 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. So I decided to kind of watch about it, like in this case 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 tapes were working for software development. So it wasn't just about writing fiction. For example, some of these advisers were actually really good tips 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 this time I was told by Jim Creighton, it's two thousand nineteen contracts fiction. And I was like, Oh, shit is not on the ME is. 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 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're staring at the blank page and you don't you don't know how to start or you don't know how to continue writing. We have the same thing in programming. So especially when you join the new team or you just open the new code base or you are maybe more of a junior, you don't really know how to 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 for me. So let's take an example. Let's say that we have this component and we have to write this component. It doesn't exist. We just received this is a task. We know what the API should be, the components of the set. You should have a fallback, which is a component that to render when the data is folding, maybe Fulbeck is not the right name to be on. But and then we have the data that's out of the component. So now if you don't have experience writing bracts applications, maybe we know something about reacts, but not really a lot. So if you follow this advice about write what you know, you can just start by just rendering the fallback. I mean, this is the really basic thing with respect, just about rendering something. So we just render the fallback. This is our first step. Then if we start reading the documentation, we will see this thing called Ustedes, which is like the basic building work about local state management, and we will just reserve place for the data. And if the data is there, we call the children, which we expect to be a function. Otherwise we just render the Fulbeck components. And at this point we already have enough. So we could start asking more questions. And I found out that this is really important stage where you have something to write on and then you build it because if you have nothing, you don't even know what to ask, actually. So the next step will be to ask someone more experienced about how to handle asynchronous operations, how to make each request. Or maybe you just continue reading the documentation, you'll probably find out on this copious 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 the position of 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 listen to some books which were they have many plotlines, they have many characters, sort of connection 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 had 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 you're telling yourself a story. When you're rewriting, you're taking out all the things that are not the story. And to be honest, if you're going to take something from this presentation, I want to be this last sentence. What I 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 in 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 of 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 drafts of something, then you should really be asking yourself, is this part of the story? And if you continue with the same component, let's say that we have to handle the 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 crushing. And we have to render a message to the screen in case in case of a 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 and we're down to the promise chain. So if there is any error, we just stood there 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 now, if it's not known, we just render this message. And here is 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 is not about copy, it's not about styling, is just about getting the data or maybe handling if there's kindling there, if there is any. So this is definitely not part of this of the story or this component. It's purely part of the story of the component which is consuming fish. So what we can do is to check if there's any error, if there is any error we could send. There is the first item. And what should I mean, this is just my choice, but could be any other signature. And by doing this all the time, by asking yourself, is this is this part of the story, you're basically writing simple components. At least that's my that's my experience.