This idea gets recycled every generation. I can’t count how many “low code” no-programming-skills-required tools I’ve seen come and go in the last four decades. Both COBOL and SQL got presented in these terms. I’ve yet to see a “non-technical manager” write a non-trivial SQL query, much less know how to confirm they got the correct results. The various 4GL tools that proliferated in the 90s led to complex amateur spa…
Translating requirements into code - is about language and tools as you have to learn the language, as you noted "few people wanted to learn to use those". Third paragraph is saying about loads of amateur spaghetti code, so turns out it was not that hard. So third paragraph contradicts things written in the second. Low-code tools promise to address "problem of the language" so it is easy to translate business knowled…
I'd actually argue differently.
It's more about a design process that requires domain knowledge, technical knowledge and the ability to assess a problem contextually.
Coding is only part of this process.