The vast majority of the code professional programmers write is code they simply should not be writing in the first place.
If we're ever going to progress beyond the 1960s programming mentality (which was brilliant for the limitations of computers then, but fails today), we need a more standardized, modular approach to programming. Platforms were an attempt to do this, but, really, much of this needs to be integrated into the language. (For all its many faults, the Ruby/Rails combo was an attempt to do the right thing here...)
This cannot really be fixed until the chasm between languages (and their data structures) and databases (as well as filesystems and object storage) is bridged well and correctly, since a huge portion of what we code is dealing (badly and inconsistently) with the crapfest that performs those mappings. Again, for all its many faults, M (aka MUMPS, a language that took a decidedly unusual approach in the 60s) was pointing the right way, here...)
From a visual programming perspective (which is really only possible once you have standardized the things mentioned above), I'd say that things like NodeRed (perhaps the best at the moment, if it were based on Lua and Tarantool, it would solve the problem I have this month...), NI's LabView, and to a lesser extent things like Matlab and Mathematica show some of the directions that we can go. We're embarrassingly bad at doing this two decades into the century. (And we cannot forget that there are a lot of propellerheads who *want* to keep this stuff hard because it makes them needed and more valuable. That's stupid and counterproductive, but the attitude is *really* hard to overcome, as it's mostly opposition through subtle sabotage by subterfuge by capable operators "protecting their turf"...)
I'd argue part of the strength of the Python community is that many of the key libraries (both core libs and defacto tools like SciPy and NumPy) have reached a point of capability and maturity that lets them be glued together fairly easily as modules - there's just not a good visual programming tool for doing that yet. (And, sadly, since Python is such a good glue language, there's less incentive to build one...)
I'm a bit surprised that we haven't seen a better GraphQL visual programming language/tool/environment yet...