I've been on this kick for a while now and the pithy version I've come up with is this: The central conceit of low- and no-code tools is that the hard part of

I've been on this kick for a while now and the pithy version I've come up with is this: The central conceit of low- and no-code tools is that the hard part of programming is typing code. I have never liked the term "coder", but it has taken a while for me to be able to articulate it. What it comes down to is this: all coding is programming, but not all programming is coding. Programming is, in very broad strokes, making the computer repeatably do something for you. Coding is typing code. Some examples: spreadsheets are programming. Yahoo Pipes back in the day, ITTT, Zapier, Microsoft Power Automate and all the rest are programming. Shell scripting is programming. Also, using any of the typical programming languages is programming. With this understanding, low- and no-code tools are obviously programming. They just involve writing less code (if they are doing their jobs correctly). This helps to understand them. If the solution domain's implementation is riddled with boilerplate, then this sort of tool can be a boon. There are plenty of instances where this is true. As the solution domain's non-boilerplate portion grows, the value of low- and no-code tools rapidly drops off. This is because -- pretty much universally in my experience -- these tools, ironically, make the act of writing code very nearly as hard as it can be. These tools, designed from the ground up with the goal of minimizing the (perceived) pain of writing code, make writing code so very difficult. So, as others have said, it is important to get tool-problem fit. And understand what it is you need to program. And if that programming challenge fits into the box that a low- or no-code tool constrains you to. Because it might not be coding, but it is definitely programming.