We Are All Hemingway

Rate this content
Bookmark

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.

22 min
17 Jun, 2021

Video Summary and Transcription

This Talk covers important tips for software development, focusing on React. Starting with what you know and building on it is emphasized. Asking the right questions and simplifying components demonstrates seniority. Reading code and asking questions are crucial for finding better solutions. The connect function in React Red Hook's library and the function-as-child component pattern are highlighted. Writing code that is easy for others to understand and maintain is emphasized. The importance of retrying on the server and refactoring for the ecosystem is mentioned.

Available in Español

1. Introduction

Short description:

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. Today I decided to share with you the most important tips which I found. And I hope you'll find them useful as well.

♪ 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.

2. Starting with What You Know

Short description:

The first thing in writing, as well as in programming, is to start with what you know. For example, in React, if you're not familiar with writing applications, you can start by rendering a fallback component. Then, as you learn more, you can build on top of what you already know. Complexity arises as you gain knowledge, both in writing and in software development.

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.

3. Writing Components and Asking Questions

Short description:

When writing software, it's important to focus on the story. Ask yourself if each component or function is truly part of the story. For example, when handling errors in a fetch component, rendering error messages may not be part of the component's story. Instead, consider passing the error as an argument to the component's children. By asking the right questions and simplifying components, you can demonstrate seniority.

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.

4. Importance of Asking Questions and Reading Code

Short description:

Asking questions is crucial for finding better solutions. However, lack of experience can hinder knowing which questions to ask. To gain more experience, reading code written by other developers is highly recommended.

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.

5. Exploring the Connect Function and Reading Code

Short description:

I was fascinated by how the connect function works in React Red Hook's library. It led me to write an article and release a library based on this pattern. However, I later discovered that this pattern was not new and had been used for years. Reading code, especially in large code bases like React, can teach you a lot.

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.

6. The Function-as-Child Component Pattern

Short description:

The function-as-child component pattern, exemplified by Formic, is a favorite of mine. It allows components like Formic to have responsibility while providing value to the consumer. Reading code from popular libraries, which often involve collaboration among developers, can offer valuable insights and smart decision-making.

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.

7. Writing Code for Others

Short description:

The code we write is not just for us, it's for others to read, maintain, and extend. Stephen King said, 'write with the door closed, rewrite with the door open.' When writing code, it's important to make it simple for others to understand and review. We should rename components and props to reflect their purpose and remove unnecessary ones. By following this approach, we can help others better understand our code, even without going into the implementation details.

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.

8. Final Thoughts and Recommendations

Short description:

If it's something on the server, we retry. The story here is about making a request and handling the error. Refactoring is about trying the code for other teammates and people in the ecosystem. Thank you for watching and listening.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Summit 2022React Summit 2022
27 min
Impact: Growing as an Engineer
Top Content
Becoming a web engineer is not easy, but there are tons of resources out there to help you on your journey. But where do you go from there? What do you do to keep growing, and to keep expanding the value you bring to your company? In this talk we’ll look at the different kinds of impact you can have as a web engineer. We’ll walk through what it means to take on bigger, more complex projects, and how to scale yourself, and grow the community around you. By driving our own development we can all grow our impact, and in this talk, we’ll discuss how to go about this.
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Top Content
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Summit Remote Edition 2020React Summit Remote Edition 2020
32 min
AHA Programming
Top Content
Are you the kind of programmer who prefers to never see the same code in two places, or do you make liberal use of copy/paste? Many developers swear the Don't Repeat Yourself (DRY) philosophy while others prefer to Write Everything Twice (WET). But which of these produces more maintainable codebases? I've seen both of these approaches lay waste to codebases and I have a new ideology I would like to propose to you: Avoid Hasty Abstractions (AHA). In this keynote, we'll talk about abstraction and how you can improve a codebase applying and creating abstractions more thoughtfully as well as how to get yourself out of a mess of over or under-abstraction.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)