As a developer you’ve probably seen or heard the famous quote;
It serves as good advice to help you avoid overengineering and reduce time to getting user feedback. But, like most rules there’s subtalties to when it should be applied.
The problem
Let’s imagine… you create a component for a page your team is working on to display a small list of users.
As per the requirements, it takes a small list of users and sorts them by name in alphabetical order. The sort should be pretty quick since there’s only a couple of items in the array, no point prematurley optimising right?
Well, a few weeks go by and you come back from a day off, greeted by a defect with your name on. It describes your teams page being pretty slow.
You take a look and see that your UsersList component now looks a little different than when you last worked on it.
While you were off there was a requirment change and a junior teamate picked up the work.
Instead rendering a few users with a simple sort, the component now renders a large list of all users with a complex (and very slow!) sorting algorithm.
Solution
In a big team with rapidly evolving requirements as a senior engineer sometimes you need to use forward thinking and apply premature optimisations. This doesn’t mean over engineer everything, but take a moment to think what good small optimisations you can make to best set up the component you’re working on for future development.
Going back to our example, we need to realise that the doing a sort on a list of items is something that could potentially take a large amount of time; even if it doesn’t right now. As an optimisation we simply wrap the sort in a useMemo hook to stop it having to re compute the sorted array on each re-render, only doing it when the users array changes.
This doesn’t just set up a good foundation for future developers to work on but can also serve as a reminder for them to take a second to think about the performance of the changes their making.
Generally applicable
This type of beneficial premature optimisation isn’t just relevant to React, the idea of setting up good foundations to avoid performance issues can be aplied to everything from CSS to architecture.
Warning
Don’t spend hours working on adding nano second optimisations to all your code, just focus on the big, easy wins. It’s about balancing the time it takes to do the premature optimisation over the time it could save in the future.
