This feels like the exception that proves the rule. Gitlab has one of the largest Rails codebases on earth. It's also been built by a decentralized remote engineering org from the start. I think that explains a lot.

Compare that to my personal experiences and that of my colleagues who work heavily with Rails: We show up to a new job at any level of seniority, spend a week or two learning the codebase, and immediately have a firm grasp of all the major components of the application. And I want to stress _firm_ grasp, since everything from the model structure to the ORM to where you can expect to find tests is standard.

Obviously no framework or convention will hold perfectly in the extremes

We use sheets all the time at work for all sorts of processes, essentially an internal tool. But it doesn't really even need code, the human is the code. I had to strongly suggest to some of our TPMs and actually a principal in the last year that no they didn't need a tool, they just needed a spreadsheet. But this is so low code that people likely don't even think of it as a low code solution, it's just a spreadsheet.

That said other than managing and sorting lists of work to do, I break the limits on sheets and excel all the time so for anything with customer scale data I can't use it.

Yep, even the most basic knowledge such as knowing how to do math on a few cells can be useful to build things. It's really good for one off internal tools to do comparisons.

For the first 5 years of selling courses I handled affiliate payouts by sorting and summing rows in a spreadsheet. It only took 5 minutes once a month. I eventually automated what I used to do manually with a script that reads the CSV file because I like coding and it was fun to me, plus I wanted to remove one point of human error.

At my workplace, they do, for all of those reasons.

More exactly, C code (hopefully MISRA C) generated from Simulink models runs much of the embedded systems in many cars. Although sometimes (cough, Toyota/Denso, cough) that generated C is then bodily assaulted by questionably competent embedded developers until it combines the worst qualities of MISRA C and low-quality embedded development, because, like many low-code solutions, getting (and keeping) everything in the low-code model is hard and the built-in escape hatch to a real programming language is not always a good fit to the problem at hand.

(As a nit, I suspect that Simulink is known and deservedly disliked by the vast majority of people with non-software Engineering degrees, given the omnipresence of Matlab in academic contexts.)

Retool has JavaScript. This is common for low code to have full languages attached.

The point is that you can do 80% of the presentation by wiring things together and only rely on coding for the most complex tasks.