If you take average risks you will, by definition, get average results.

Instead of minimizing risk, I instead like Jeff Bezos’ pursuance of regret minimization. Of the paths that you can take, which path will most likely result in the least regret later in life?

-- Steph Smith

At work I keep seeing cases where there is overlap in common behavior but not completely. Special cases take a simple routine and wrench it through with conditions.

With React components, it’s often easy enough to split out the separate cases as their own components or, more recently, maybe push the differing behavior into individual hooks.

Some of the uglier cases are in Redux reducers, action creator functions, or async API-calling code. These functions start small and simple, but as the requirements grow and change over time these streamlined functions quickly grow branches, and those conditions then grow their own complexities in due time. Eventually it becomes a dense forest of possible code paths where bugs grow freely.

I’ve been trying to tame some of those areas recently by simply trying to separate what is common from what is different. A wonderful benefit of doing that is being able to clearly see what is different just from how the code is structured.

I’ve come to look at significant branching as a code smell, and try to refactor so that the branching happens once, up front, where you pick from a handful of top-level functions or objects that themselves are focused & single-purpose. I think that insight came from Sandi Metz & her 99 Bottles book; it’s an enormously powerful tool, and so far has been a great help.

Interestingly, Javascript’s prototypal inheritance is quite well suited for this kind of thing.