[foobarbecue]

I wonder about this:

> A templating language ... targets a weird imagined archetype of someone who isn't allergic to code, but somehow isn't smart enough to work in a genuine programming language. In my experience, this archetype doesn't actually exist.

In my day job, I write "sequences" to command a spacecraft, in a neutered "sequencing language" with conditionals but no looping. Several people on our team who are great at writing sequences for the spacecraft feel they "can't code" and don't learn other languages. I had assumed the deal with templating languages was similar and this type of people were the target users.

[williamcotton]

Creating ways for people to interact and control a computer by writing but who don’t need to know about deploying to production, scaling databases, managing memory resources, etc, seems like a good division of labor.

There are two forces at work here when this division of labor disappears: 1.) increasing complexity in the tool designed for non-computer engineers and 2.) the subtleties of a class of worker who don’t want to do literal manual labor like typing in SQL.

At many firms it seems as if there is a layer of operations that is only capable of interacting with a CRUD UI, constricted either by ability or tooling.

That is, there is a pressure from management to split a firm in two: those that code and those that do not. This means that even something as simple as making updates to a CRUD interface is entwined with the the rest of the engineering practices.

Case in point: computer engineers writing SQL at the behest of some other entity at a firm who is not capable or allowed or even encouraged to learn or understand SQL.

[KronisLV]

> Creating ways for people to interact and control a computer by writing but who don’t need to know about deploying to production, scaling databases, managing memory resources, etc, seems like a good division of labor.

I guess it depends on the domain and the lines along which you want to divide your project along. If someone can write back end code but doesn't really know that much about databases, you might end up with an application that does hundreds of database queries just to display one application view or prepare a REST query response.

If someone counts as a full stack developer but ends up producing a singleton app that cannot scale to more than one instance (e.g. stores important data in application memory, even things like user sessions), then you also probably have a bit of a problem on your hands.

If someone counts as a DevOps engineer but doesn't think too much about security, you might end up with a database instance that's publicly available, increasing the attack surface of your system a whole lot.

You can have a division of technical and non-technical folks, you can have a division between the different types of technical folks, but you absolutely do need at least someone who can wear all of the different hats (e.g. partake in a particular role) out there, in addition to them being present at the correct time to bring up things that are actually (or should be) blockers, which would otherwise get overlooked and would result in a horrendous implementation.