The Greatest React Developer I Ever Met

What makes a truly great engineer? Over the last five years, I have worked with people from young blood to veterans. But as the saying goes, very few people will scratch the surface of your mind.

Today, I will share the story of one of the most outstanding engineers I have seen. And the weird part is I realized how awesome he was only after he left the organization.

Let’s begin…

He was not the fastest

Once, we were aiming for a monthly release. At the end of the sprint cycle, a new requirement for creating a role-based authorization mechanism in the front end came.

As the back-end code was already there, the management wanted to push this to the next release.

However, he refused to do it, and the management was unhappy.

I was a junior then and thought, why did he do that? From the description, I understood it was possible to do it within two days. But still, he just straight out refused to do that.

It’s not all about speed.

This type of hasty work has become a norm in start-up culture, but later in my career, I realized why he was right. Maybe 99% of the time, this practice doesn’t hurt, but the remaining 1% can damage the company or even sometimes a person’s whole career!

His code read like a poem

Much later, I had the privilege to work on his project after he left the company (due to conflict with management).

It’s a shame that I couldn’t understand my code (if I looked at it after 3–4 months), but his code was so beautiful that a junior developer like myself had no problem understanding what was happening there.

Here is an example.

export const SomeComponent = () => {
  
  const userInfo = getUserInfo();
  
  const profileDetails = getProfileDetailsOfUser(userInfo.id);
  
  const aboutData = extractAboutData(profileDetails);
  
  const personalData = extractPersonalData(profileDetails)
  
  return (
    <UserDetails>
      <About data={aboutData} />
      <PersonalInfo data={personalData} />
    </UserDetails>
  )
}
 

It’s hard to appreciate it inside a 3-minutes read Medium article but once you start working on a project with hundreds of components, this piece of code can bring peace inside you.

He cared about best practices

It was from him I understood the importance of following the best practices. These are hard to understand as a junior dev, but as time passed, I understood how following best practices automatically helps write cleaner code.

He had an extensive Eslint setup. I can still remember there were like 30–35 rules there. I didn’t even understand many of those back then.

He had his way of doing things

One thing that baffled me about his code was his verbosity. He would name the functions in a particular but consistent fashion.

Let me give a very simple example. We need to sort an object array very often, right? A quick Google search would give something like this, and we would just change the property name.

sortedArray = objs.sort((a,b) => (a.last_nom > b.last_nom) ? 1 : ((b.last_nom > a.last_nom) ? -1 : 0))
 

But this was not the same for him. He would do something like this.

function compare( a, b ) {
  if ( a.last_nom < b.last_nom ){
    return -1;
  }
  if ( a.last_nom > b.last_nom ){
    return 1;
  }
  return 0;
}

objs.sort( compare );
 

Both of these do the same thing but in his way, I would not have to scratch my head and look at the code for 2 minutes to understand what’s going on there.

Later in my career, I understood that meaningful names are more important than reducing two lines from your codebase.

In the long run, everything is about maintainability and reducing technical debt. And he was a master of it.

He was against change

After the hooks were made official, the community rushed towards re-factoring their codebase into functional components. But he didn’t let us do that.

Yes, that was maybe not a good idea then because now almost every new codebase is written with functional components, but despite that, he wanted us to wait.

Every new technology/library is like a shiny toy. Everybody loves to play with that. Now and then, some new library comes along, and we think about how we can use that inside the project.

But he refused to add those almost every time. I have to admit that I felt a little annoyed at times. Sometimes, I even thought that maybe he refused those because he didn't know how to use those libraries himself.

But as time marched on, it became clear that he was aware of the new changes but was very careful about using them. He understood that adding anything and everything has its own cost, especially in the JavaScript world.

He left

After 6–7 months, he switched jobs because of some conflict with the management.

So, the project that he maintained came to me. I started to go through his codes and later realized how awesome he was. On the surface, we were doing the same job. Delivering features that were being asked.

But inside the code, what he did just blew me away. From the folder structure to naming variables, the care he put into each line of code made me fall in love with programming. I realized:

A good piece of code is a thing of beauty!

And I still carry this philosophy with me.

Conclusion

We had our differences in opinion while we worked together. Maybe he wasn’t always right; maybe he had some issues with an expression that made him unlikeable.

Nevertheless, he is the most excellent React developer (maybe the most significant developer).

Do you know somebody like this?

Have something to say? Get in touch with me via LinkedIn