When this kind of thing tries to surface, it’s a warning that you need to 10x your understanding of the problem space you are adjacent to.
The classic and oft heard “How did this ever work?”
By all means you can gain a lot by making things easier to understand, but only in service of shortcuts while developing or debugging. But this kind of understanding is not the foundation your application can safely stand on. You need detailed visibility into what the system is genuinely doing, and our mushy brains do a poor job of emulating any codebase, no matter how elegant.
FP can be good for that but I often find that people get so carried away with the pure notion of functional code that they forget to make it obvious in its design. Way, way too much “clever” functional code out there.
The data structures are the key for many things, but a lot of software is all about handling side effects, where basically everything you touch is an input or an output with real world, interrelated global state.
That’s where correctly compartmentalising those state relationships and ample asserts or fail-soft/safe code practices become key. And properly descriptive variable names and naming conventions, with sparse but deep comments where it wasn’t possible to write the code to be self documented by its obvious nature.