Similar to TDD or Domain Driven Design (DDD) we should aim to write code that is easy to debug. Store intermediate values in a pipeline in variables, store predicates in a variable with a human readable name, and avoid in lining complex function calls.
There are other techniques that serve this purpose and additional reasons than what this article explores of how or why this is helpful.
I understand the problems that higher level debuggers take time for someone to build, install, or at least train on using, and that's often time that projects can't afford, but there can be huge benefits to Developer Experience if you build or find debuggers specific to your abstractions, especially in places like functional programming pipelines.
(As some easy examples, I've worked with the Redux Dev Tools a few times and getting a "redux-eye view" of an application's data state is sometimes incredibly more useful than trying to add a bunch of console.logs into all your actions and reducers manually. Similarly, I've become a big proponent lately of using RxJS-Spy for RxJS work: it adds a single operator `tag('pipeline-name')` that is a no-op in Production builds and then gives you a great Dev-time API for observing [or debugger breaking] specific pipelines or pipelines filtered by regex of name, all without manually adding or removing `tap` and `console.log` in those same pipelines.)
We don't always have to stick to lowest common denominator debug tools. We don't still need to make sure that we can pipe to our dev terminal over serial port to get our debugging done or log everything to plaintext files that are hard to manage. I think sometimes people forget that.
Similarly, I do find a responsibility that if I write code that is best debugged with higher level tools, that I make sure to document those tools, and try my best to train people on them as they ask.
It's something I regularly say to our juniors - if you have two ways to do something and one is much easier to debug later, it's probably a better choice. It's a nice extension of not writing unnecessarily overcomplicated code and keeping things readable.
I have to remind myself of this concept often as it’s just so easy to do things quick and dirty
Both Barry's think the other is an insufferable asshole.