An HR Manager’s Guide to Hiring React-Redux Developers
(The opinions herein are of the author and the author alone especially since David is probably going to punch me in the face when he eventually reads this. Also, this post has been written for a non-technical audience from the perspective of hiring and project management so if you want to have a discussion about how awesome singleton state management is, the ergonomics of JSX, typescript vs ES.X, the subtleties of the virtual DOM, or design patterning of Components, I will gladly discuss more technical subjects in the comment section.)
As with many technical leads these days, I am looking to find React-Redux (R-R)developers to work on our larger front-end heavy projects. As such, I am realizing just how incredibly important it is to not just consider the skills a person has, but also what are the connotations and nuances that those skills bring to the table and how does this actually effect team composition, workflow, and overall development culture.
In reference to the challenges we face at Proof. We are dealing with a rapidly changing industry (Blockchain/cryptocurrency/data science) as well as rapidly moving goal posts when it comes to market validation. Combined with the strangeness of web development as a whole, we are constantly facing a push and pull between speed, stability, and cost. This leads to all manner of issues when considering hiring.
After many months interviewing and slowly converting my Angular2+ specialization to React, I have come to a (probably) controversial conclusion that there exists only 2 designations of R/R Developers when it comes to hiring for a startup:
- Neophytes.
- Seniors.
Labels aside, what I am attempting to highlight is the extreme Delta one encounters when trying to find a React-Redux skillset.
This isn’t an insult. I am absolutely a neophyte when it comes to React but after managing a React/Redux/Flux codebase and React developers, I have noticed some idiosyncrasies that exist with this particular group of developers, stemming from the tech. In other words, I have developed a strong appreciation that React and Redux are not merely just a new flavor of framework.
When it comes to React (a lot of the stuff in this post can be applied to Angular as well) A person with junior or intermediate experience in the tech will create inefficiency and an extreme number of managerial headaches. This often leads to unrestrained technical debt growth and developer burnout. Much of this stems from the reality that React/Redux is just as much a framework for thinking about frontend development as it is a framework for web development.
Likewise, the labels have assisted me in understanding how the R/R stack itself can contribute to burnout, slowdown, and project inefficiency if lessons from the early days of a startup aren’t culled and properly applied. The reason for this boils down to 3 main reasons:
- Effective React and Redux usage is highly oriented towards following conventions
- Appropriate project management with React-Redux requires a staggering amount of documentation.
- And finally, React and Redux are most appropriate for large scale systems
Before carrying on, I would like to reiterate- this is not a criticism of React. Rather, I am a subscriber to the ‘tool-belt’ mentality wherein frameworks and even coding languages are tools that need to fit the problem at hand. I really dig React and I especially like Redux but I do believe they are ideal for a specific set of very large problems and extremely inappropriate for others. For example, I adore Django and Rails, however, they are far too heavy for many micro-service builds that can more easily and quickly be done with a basic Flask or LAMP build.
I believe the trick is to be highly cognizant of a project’s needs and life-span while attempting to find talented people to work on said project rather than choosing an underlying tech out of convenience or popularity.
* Effective React and Redux usage is highly oriented towards following conventions
The reasoning for this stems from a fundamental aspect of web development that usually gets summed up as “The DOM is slow” (which is kind of true) which means in business terms that creating apps that do all that fancy schmancy moving around and transition animation and changing of names and updating prices stuff has a high cost (sometimes). The reason for this is really big and weird and requires a level of history that is outside the scope of this post.
In the most reductive terms, it is best to avoid making changes to the DOM for as long as possible. Frontend developers are in a constant game of ‘the living room floor is lava but I need to make a sandwich’ where the floor is the DOM and the sandwich is actually throwing information at someone.
React was built to assist this intent by avoiding the DOM for as long as possible, causing as few layout writes as possible by structuring data hierarchies in a ‘virtual-DOM’. Likewise, Redux is a mechanism to help discipline this process and create a more streamlined way to handle the current stuff (or state) a user sees by creating a single point of truth rather than keeping a bunch of disparate memory structures sitting around inside a site.
Since React is essentially allowing code to avoid doing something it is eventually going to have to do, there exist many different ways to eliminate many of the upsides of the technology. Likewise, Redux is one of those technologies that doesn’t make sense at first. Why not just make a few Ajax calls and update using a basic Element selector and then keep the value in an Javascript object if I need it later? I mean it’s easier to do a direct reference than write a bunch of components and plan out dataflows…
Until a developer has the deep psychological scars from trying to manage the speed, state, presentation, and scale of a giant application while trying not to pound their database into the ground, they will understand neither the benefits nor the reasoning for using React or Redux. A developer who slavishly follows convention with no heed to the reasoning for that convention is at risk of running afoul of those reasons while following all the conventions.
React, like Javascript itself, is highly forgiving in some ways while being brutally straightforward at the same time. It is easy to accidentally re-render a page tens of times when moving data around components. It is easy to mutate data wrongly and then spend hours trying to find out why your perfectly good code isn’t updating the page. It is easy to use all of the best practices, write perfectly acceptable code, and get a site running, but at the end of the day you have completely eliminated the gains you would get from an R/R stack for 10 times as much code.
* Appropriate project management with React-Redux requires a staggering amount of documentation
Documentation is essential for reducing technical debt but finding a middle ground between documentation and actually building product is also important.
In order to do basic things in React-Redux, the application requires a substantial amount of code. The developer needs to first create a service which actually gets and shapes the data it needs, build actions to update the site, and then create reducers to describe those updates. After this, the developer needs to architect a tree of components that properly arrange and present the changes. By the time you are done you can have hundreds of lines of code spanning 4 or 5 modules just to get some data from an api and render it to a page. Multiply this across an entire project and you are left with a massive codebase that needs to be maintained and managed.
This is not inherently a bad thing. A production-ready project will eventually have a consider amount of code after validation, testing, and edge casing are hunted down and accounted for. However, for many frontend technologies (including javascript itself), this level of engagement is not mandatory upfront.
Bringing someone onto a React project of almost any size thus requires that someone to go through a considerable amount of code prior to actually getting to work on said project. The only way to speed up this process is to ask a sitting developer to write reams of documentation prior to an off-board or mentor the incoming developer in the technology.
Not doing either hazards almost immediate burnout on the part of the incoming developer as they are tasked with working on a massive codebase with the deadlines of a tech company seeking funding. Luckily, a good implementation of the above mentioned conventions can mitigate this issue but once again we fall into the need for all your React devs having a solid grasp of the conventions.
The solution to this is to document and test both in-code and alongside the code as the application grows. This brings a new set of skills mostly found in veterans. Documentation and testing are skills gained through study and practice and the art of writing useful documentation and tests is largely honed through experience.
Luckily, there are scores of good documentation examples to help along the progress. Unfortunately, a fair amount of React training material has been put behind a walled garden of pay-to-play tutorials teaching developers how to make to-do lists…
* React and Redux are most appropriate for large scale systems
Addendum to the above: with large teams.
One of the main positives to extensive usage of ‘convention over configuration’ is that there is often a much easier-to-grasp code vernacular for a team. All standard practices can align with what the majority of other devs use while any deviation from the standard can be described against a common baseline.
However, when the code base is large and deviation from convention is punished harshly by the tech, a team’s capacity for experimentation, pivots, and responding to customer feedback is directly related to that team’s level of experience.
Anything that stands in the way of building that experience or rapport is going to hold back development and suggests its own kind of technical debt.
In some ways, all frontend frameworks are only appropriate for large projects since vanilla javascript and a high level of knowledge about browsers can solve many problems very quickly. Within Javascript itself, there already exist hundreds of solutions that solve most problems quicker in terms of development and just as effectively as a React and Redux stack. An effective use of these incumbent technologies can create the same effect as React and Redux while costing much less time.
That is to say, both R/R are extremely pleasurable to learn and use, they are highly ergonomic but do not necessarily contribute to development speed — much less the actual speed of an application… unless, once again, the people working on the project have a high level of knowledge and experience in both React and Redux.
Part of the reason for this is that the gains of using React and Redux when it comes to speed are exponential. In the early days of a project, React requires a high amount of preparation, tasking, and architectural planning but as you go on, your team will have quite a bit of reusable code and iteration becomes much quicker. Of course this is only true of the code is well documented.
Robust planning is good practice for starting any large product but if you are rapidly developing for a PoC or expect rapid technological pivots due to market conditions, having tools that necessitate planning can quickly exhaust a team that needs to architect even the most simple of API calls.
Neophytes & Seniors Redux
And, this gets us back to my original point… when it comes to hiring there are two types of React/Redux coders, Neophytes and Seniors. Approaching a React/Redux project with the expectation that a new person will get the most out of the technology extremely quickly (especially if they are working on an existing codebase) will cause much consternation if there is even the smallest deviation from convention. Likewise, if the expectation of the business or product people is that a new developer means immediate productivity (which would be soooo nice) they will run any new developer, senior or otherwise, into the ground. This goes double for React/Redux due to the nature of the work.
The reason, as technical managers, hiring specialists, or otherwise that we should reassess how we approach React/Redux development is rooted in what React/Redux represents. To be honest, React/Redux as technological paradigm is currently a fad. It is. Keep in mind, good chunks of web development are fads. Web development is still a pretty young discipline (hell computational engineering is pretty young by the standards of existing disciplines). This isn’t necessarily a bad thing. However, it is essential for us not to fall into the trap that ‘newer is better’. There are many hills with the bodies of Drupal and Flash developers attesting to this. Rather than “hiring for React” I propose a different set of standards for engaging incoming frontend developers. It’s a simple idea:
Find people with good core skills in programming concepts, ES6+, core Javascript, DOM manipulation, memory management, and after that, then look at their framework stack.
Even dividing your team into two or more groups, one for rapid PoC development and one for methodical design, architecting, and iteration.
After this, ensure your technical managers approach the new hire with the right expectations. Merely looking for “React and Redux” in a resume or completely passing over an experienced developer for lacking the keywords is not good enough for you, your company, your product, or your customers.
So to reiterate what I said above: this is not a criticism of React/Redux wholesale and I am not trying to attack React developers who are just starting out. Rather, I am attacking the mindset that trivializes the learning of a framework as merely a ‘set of skills’ that one needs to hire for. React/Redux is representative of an approach that will exist as long as web technology continues to have a number of fundamental protocol problems. Hiring for these skills should require deep thought and consideration by an HR team starting with this question:
Is React/Redux even even a good fit for the project?
Just because your work is fundamentally ‘business’ does not mean you should be totally ignorant of the code that makes up your business. Regardless if React/Redux sustain into the future in the same way Node.js or Jquery have, the Javascript ecosystem is going to be a labyrinthine place for quite some time and hiring and expectation are the first piece of the map for negotiating the maze.
