Presumably we would agree that writing a web app is more economical in Python, Ruby, Go, etc than in C or ASM. Both C devs and HLL (higher level language) devs are well-paid and well-versed in their tool set. The difference is that HLL devs can deliver value at a higher rate than C devs for this domain.
If we can agree on the above, then presumably it's conceivable that the same abstraction principle applies with low code solutions--yes, low code users will know their tool well and earn loads of money, but they will probably move faster than traditional programmers for this domain.
In my mind, this only holds as long as these low-code tools are really more abstract and not just a visual/graphical programming language (I'm sure there are very low-level visual programming tools that would allow you to manage your own memory, etc). It also depends on the domain being amenable to abstraction--if you have to drop out of the tool with some regularity to do things the tool doesn't support (e.g., performance, custom analytics, etc), there's a threshold at which the overhead of calling into a lower level language exceeds the benefits of the tool. I don't know where this threshold is, largely because the domain isn't well defined.
But I do think low code solutions are conceivable for certain domains. I would make the argument that Microsoft Access and Excel either qualify as "low code" solutions or they are at least proto-low-code solutions, and they both deliver tremendous value. I would perhaps even say that Access/Excel are to client-side applications what these new low-code solutions are to web applications. Not a perfect analogy, but I think there's something insightful in there.
If we can agree on the above, then presumably it's conceivable that the same abstraction principle applies with low code solutions--yes, low code users will know their tool well and earn loads of money, but they will probably move faster than traditional programmers for this domain.
In my mind, this only holds as long as these low-code tools are really more abstract and not just a visual/graphical programming language (I'm sure there are very low-level visual programming tools that would allow you to manage your own memory, etc). It also depends on the domain being amenable to abstraction--if you have to drop out of the tool with some regularity to do things the tool doesn't support (e.g., performance, custom analytics, etc), there's a threshold at which the overhead of calling into a lower level language exceeds the benefits of the tool. I don't know where this threshold is, largely because the domain isn't well defined.
But I do think low code solutions are conceivable for certain domains. I would make the argument that Microsoft Access and Excel either qualify as "low code" solutions or they are at least proto-low-code solutions, and they both deliver tremendous value. I would perhaps even say that Access/Excel are to client-side applications what these new low-code solutions are to web applications. Not a perfect analogy, but I think there's something insightful in there.