We Hire React Developers

“We hire React developers”. Sadly, that doesn’t really hold up; you’ll need to be wayyyyyy more specific. What does “React developer” mean?

Some write JavaScript, some write TypeScript.

Some use classes, some use Hooks.

Some use imperative/procedural style components, some create pure ones, some use higher order components, some use Mediators, some utilize functional core/imperative shell, some practice a variety utilize a combination thereof, and others have no idea and just inject hooks until they’re “done”.

Some test first, some test last, and many test not at all. Some think hard about architecture, others let it emerge, and others have no idea what that means “because they’re just self-contained components that you wire together”. Some think unit tests are a waste and you should only do end to end tests as “they actually test the website and CSS”, others live and breathe Storybook, some heavily rely on snapshot tests, and a few realize that different projects have a higher need of certain tests, while others vehemently view all of that as a waste “because I can quickly refresh the page and see the bugs”.

Some love SASS, some practice “real, raw, original CSS”, some use Tailwind, and some use Emotion, and there are a variety of CSS-in-JS followers. Some have the mental capability of using CSS for 90% of interactivity, and others copy paste JavaScript from StackOverflow to get rounded + masked corners.

Some utilize ES6 modules via Webpack, others utilize Parcel, some ESBuild, and others have no idea how any of those work by utilizing a build system like Create React App or Vite. Some know of Vite, but have been using Create React App for 3 years “because the app utilizes it and we don’t know why we’d upgrade or how or what the cost/benefits are”. Some enjoy tinkering with build systems, some hate it, and some hate web dev solely because of this. Some believe you don’t need build systems. Some believe you don’t need build systems, except for CSS. Some think you should minify code, some think you should uglify it, some think you should do both, some think neither have good return on investment, and others say it depends on various factors. Some think this applies to HTML as well.

Some believe in Object Oriented Programming, and some of those believe in SOLID, and a few sling Design Patterns. Some believe in Functional Programming and somehow make it work. Some either don’t know what either of those styles are, or don’t care, and code in a procedural way.

Some think you need types, some do not. Some think all you need are records, some think sum types are worth the TypeScript squeeze, some think both. Many are ok with primitives, while others vehemently avoid primitive obsession. Some attempt to bring category theory with them, while others just long for a pipeline operator and use Promises.

Some use JSON. Some parse the JSON to types. Some separate the UI and API into Bounded Contexts, while others create many bounded contexts. Some orchestrate to call many API’s from the UI, while others utilize Back-end for Front-ends in an attempt to avoid AJAX Waterfalls. Some would prefer to do any of the above, but can’t “because legacy mess”.

Some care about the user, some want to but have no idea who the user is, and others don’t care. Some love programming, some hate it, some have no idea, and others are just using it as a stepping stone to management. Some constantly question why they’re doing this, others can’t imagine doing anything else.

Some use React for Single Page Applications, while others utilize Next.js or Astro. Some are building actual, highly interactive applications that require a lot of client-site where others are simply shoving JSON from the database into pages. Some utilize routers, others have no URL’s and all route state is in memory.

Some love React, some hate it, and some have no idea there are other frameworks, or why they’d change. Some only do it because of the job opportunities, while others gleefully love it.

Most importantly, none of the above is static. Developers change as they grow, and any combination of the above can be a different combination the next day.

You don’t “hire” React developers. You’re hiring a developer to come into your culture, and how each mesh and change each other, or not, is complex. They may influence developers within their team, their organization/department, or the company, or they may not. The company in turn based on the type of work they do may heavily influence the perspectives of the developer which can change the above combinations, or it may instead galvanize what they already believe. They may alienate other developers, or form extremely strong bonds.

How people use React is complex. You may have an idealized checkmark list of the above you expect devs to check off, or only hit 2 out of the 5 as they can learn the rest on the job.

The next time someone says “We use React to make it easier to hire developers”, you know they don’t really know what that actually means.