8 Ways to Spot A Great React Developer
Tags: javascript, webdev, tutorial, react
Published: 2021-11-23 09:00:05

---
title: 8 Ways to Spot A Great React Developer
published: true
date: 2021-11-22 16:48:32 UTC
tags: javascript, webdev, tutorial, react
canonical_url: https://www.upbeatcode.com/react/8-ways-to-spot-a-great-react-developer/
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fk0vsgwk449tlq2alc8w.png
---

 **Let’s just agree on one thing! There are a lot of good developers out there.**

However, there is quite a lot of bad ones as well. And I feel very confident to say, you’ve already seen both. If not, you might just have been lucky. But most likely, you just haven’t been in an industry for a long time.

Or maybe just weren’t looking closely enough. Maybe you don’t know how to differentiate them. You don’t know what traits to look for in a great developer. And you don’t know how to identify a bad one. Either way, there is no reason to be worried. Because today, I’ll teach you how to separate the best from the rest.

I’ve been around developers for quite some time. And I was given the privilege to experience both worlds. I’ve seen the best, and I’ve seen the worst. But being the optimist I am, I decided to focus on the positive.

I tried to remember all the things that impressed me on good React developers, and list them in this article. I encourage you to read until the end. But if you just came here for the list. Here it is...

**These are the 8 ways to sport a great React developer:**

1. They Evaluate Each Dependency
2. They Use Type Checking
3. They Understand Bundlers
4. They Don't Define Functions Inside Render
5. They Are Consistent
6. They Don't Mix Application Layers
7. They Keep It Simple
8. They Know Advanced Patterns

# They Evaluate Each Dependency

The node package manager is just great. It comes with all the great packages created by the community. _If it wasn’t for npm, I don’t think JavaScript would be in the place, it is today._ If you’re facing any problem, there is a high chance someone else was in the same place. They already implemented the solution. And they were kind of to share it with you in a form of the npm package.

_Needless to say, npm is a huge asset for development. However, it can paralyze your thinking. You’ll end up solving each problem with a new package. And eventually, your bundle will grow in size as a bodybuilder on steroids._

In my defense, I’m not saying importing a package to solve your problem is bad. There is nothing wrong with it. But the action that separates good developers from the bad is the act of doing research.

Newbie developers just import any package without thinking. If it worked, they just move to another problem. On the other hand, coders with more seniority will evaluate the package. They’ll check the licensing or community behind it\*. They’ll also use tools like [bundlephobia](https://bundlephobia.com/) to check the size and package details.\*

_Can you think of someone who does these things? Study them, learn from them!_

# They Use Type Checking

I have to confess. When I started to learn React, I saw a lot of people using type checking. I knew what was the purpose of PropTypes, but I didn’t understand why.

I believed the whole purpose of JavaScript is to not care about the types. But as I started working on more complex projects. And gaining more real-life experience, I quickly realized type checking is my friend. And it’s also necessary to deliver a stable and bug-free product.

PropTypes quickly became my good pal, but our friendship was a bit shaky. I noticed we have a problem. I could only see type errors when components were rendered. And this made it very easy to miss them.

In the back of my head, I knew Typescript would solve this problem once and for all. And when I noticed all the big companies are starting to adopt it. I knew I was right. Typescript is a way to go.

You don’t need to learn Typescript to become a great React developer. But you should use some form of type checking. And you should use it properly. Using Typescript or PropTypes doesn’t magically make you a good developer. You need to make sure to type properly (which can be a guide on its own).

For starters, try to follow these simple rules.

- Don’t use `any` in Typescript
- Use `PropTypes.shape` instead of `PropTypes.object`
- _Use `PropTypes.arrayOf` instea_d of `PropTypes.array`

# They Understand Bundlers

Have you ever seen developers doing changes in a Webpack configuration? Let’s just assume they’re great. Otherwise, they wouldn’t even date to look into that file. I don’t think bundlers are hard to learn, but they can be intimidating at first. And if someone feels confident to look into that config file, they probably know what they’re doing.

However, do you need to know how they work? Probably not, you can treat them like a black box. After all, tools like [CRA](https://create-react-app.dev/) makes it easier for you to start without zero configuration. But as you’re becoming more experienced, you tend to look for improvements and optimizations in your workflow.

And to do them, you’ll have to look under the hood. But don’t worry, as you’ll quickly figure out, they’re not so hard to learn. Tools like [Webpack](https://webpack.js.org/) or [Rollup](https://rollupjs.org/guide/en/) are very well documented. And changing something in the configuration is just a matter of one or two lines.

If you want to improve as a developer, I highly recommend starting to learn about bundlers.

# They Don't Define Functions Inside Render

I’m pretty confident to say, you defined at least one function inside render. I know I did, but each time I do that, I just had a weird feeling. Something just didn't feel right.

In a way, there is nothing wrong with it. At least not when used in a simple component. But when your components grow in complexity. It’s better to have all the functions defined together. Not hiding them inside the render function. By doing this, you’re separating display logic from functional logic. And eventually, you’ll make your component way easier to read.

_Your coworkers will love you for doing it._

# They Are Consistent

There is one thing I love the most about React. It’s unopinionated. And while this can be seen as an advantage, it also comes with a cost. The cost of doing one thing using different approaches. This very thing can quickly introduce some problems. Especially when multiple people are working on the same project.

_What separates good React developers from bad is that they’re using the same approaches consistently_. They write components in a certain way, they handle state in a certain way. Every single paradigm is handled using the same approach, over and over. Needless to say, you’ll have a lovely time going through this type of codebase.

But great React developers don’t even use the same patterns consistently. They go one step further\*. They’re making sure the same level of consistency is maintained across the project. Sometimes, it can be a pain in the ass. But in the long run, your project will become easier to maintain.\*

# They Don't Mix Application Layers

Have you ever looked inside the component and immediately got scared? You found yourself staring at the code, not knowing what is going on. Most likely, this component was taking care of multiple things.

_Keeping track of the state, handling business logic, and while we’re doing all of this, let’s just fetch the data as well._

These components are very hard to manage. But more importantly, they’re hard to understand. Maybe someone understood them at the time of coding. But looking at them a couple of months later, that’s a whole different story.

_Good developers understand the architecture._ _They know how to think in separate blocks._ _Each block of the architecture should have a specific purpose._ _Have you ever been encouraged to separate business logic, state management, or data fetching? Well, the person who told you that was a great React developer._

# They Keep It Simple

Simplicity can be explained as the art of not complicating things. To give you an example, it’s very easy to write sleek one-liners in JavaScript. At first, they can look good. And you may believe your co-workers will preach your skills. Just because you can write one-liners like that. But in reality, they won’t.

One-liners save space, I can’t argue about that. But in the long run, they make code hard to read. Just look at these 2 code examples. They both do the same thing. But one of them is easier to understand. Which one do you think it is?

```
const numbers = [27, 52, 28, 122, 67];

// Example 1
const average = arr => arr.reduce((a, b) => a + b) / arr.length
console.log(average(numbers));
// => 59.2

// Example 2
const anotherAverage = arr => {
  const sum = arr.reduce((partialSum, nextNumber) => partialSum + nextNumber, 0);
  return sum / arr.length;
}  
console.log(anotherAverage(numbers));
// => 59.2
```

# They Know Advanced Patterns

React has a very fast learning curve. Just by using one of its simplest APIs or concepts, you can achieve amazing things. You don’t even have to learn advanced patterns. And still, you can build awesome stuff. But does it mean you don’t have to learn advanced patterns?

_React comes with advanced concepts like Context, Portals, Compound components, or render props._ And they’re included in the library for a reason. They’re there to help you to solve your problems. However, by you refusing to learn them, you’re limiting yourself. And you’re limiting your application potential.

Great React developers know these patterns in and out. And they know their correct applications. You may think these patterns are complicated. But in reality, they’re very well documented and easy to understand. All you have to do is take a little bit of initiative. And start looking at the advanced section of [React Docs](https://reactjs.org/docs).

# Conclusion

Our job as developers is to make sure the job is done. But there is one thing that separates the best from the rest. Great developers will make sure the work is done, but they’ll also care about how it’s done.

All the qualities mentioned in this article. They help to make sure the development goes smoothly. And that all team members have a good time working on the project.

I’m not saying you need to have all these traits. And I’m also not saying there are no more qualities that make a great developer. But if you know someone who does at least half of these things, they’re probably good. And if you do them yourself, you’re most likely a great developer too.