3 ms·

During my time at these corporations, I saw 3 hierarchies of work: 1. backend service - APIs/talking to databases, message queues, or caches/talking to other A

During my time at these corporations, I saw 3 hierarchies of work: 1. backend service - APIs/talking to databases, message queues, or caches/talking to other APIs/doing light data transformation 1. UI - giving the user tables of data/links to other tables of data/giving the user basic CRUD operations around data through backend services 1. batch jobs - hourly/nightly/weekly jobs that perform basic logic over some form of input and generate some type of output/response (lines from a file, database rows, messages from a queue) I'm obviously playing devil's advocate when I pose this question (along with oversimplifying the entire nature of technical programming work). If a "savvy Excel" worker or your average technical documentation writer was given a specific plain English format (kind of like a programming language) to follow that compiled to a deployed service (REST endpoint), batch job, or UI page, how far would this get at replacing the bottom 30-50% of programmers? On top of that, what would be stopping this English-to-deployed-code from replacing say, the top 85% of programmers? I think I'm focusing too heavily on the web development industry (this obviously wouldn't work for something that needs to be performance optimized like a game engine), but I also don't know if that's a bad thing. The web development industry is probably large enough to be solely focused on for the point of this hypothesis. I'm sure this has been tried before but I don't know what terms to search for to research. I do also think that once a "business analyst" understands how systems work (pass certain types of request parameters into a function that does filter/map/reduce/calls other functions/loads other data, returns a specific response format), they are pretty much a programmer at that point, right? Maybe the overlap of "people who write technical requirements for corporate software deals" and "people who understand code flow" is very small and I'm proposing something very dumb. Curious to hear the thoughts of those smarter than me!

lhorie 8y ago
Even if you assume programmers are replaceable code monkeys, you seem to be ignoring a large portion of what their responsibilities involve: fixing bugs, writing tests, integrating 3rd party libraries, managing version control, etc. Simply changing from programming language to one with a different target audience isn't going to make those responsibilities go away; you'd just be pushing them to people who don't necssarily have the skillset to translate a requirement to the highly strict format that a programming language provides. Your idea is analogous to saying "if only I created an amazing enough 3D printer, architects would no longer require engineers and construction workers to erect a building". But this ignores the fact that an architect doesn't know the first thing about bylaws, material strength, logistics, rain, etc. In reality, now the architect would be responsible for having the expertise of one or more other prefessions.
- MuffinFlavored 8y ago
  > fixing bugs I like this counter argument because as a developer, it stinks tracking down bugs. In a perfect world, if the English to code compiler worked pretty well, couldn't the blame of bugs be moved to the business analysts writing the requirements? > writing tests if the code does exactly what the business requirements say, why are tests needed? > integrating 3rd party libraries a huge portion of programming to me is "calling a function or an endpoint of a 3rd party library". to me, that could very easily fit into the plain English format I'm proposing for this "technology language"
  - lhorie 8y ago
    > if the English to code compiler worked pretty well, "In theory, theory and practice are the same. In practice, they are not" In practice, the so called "english to code compiler" is an abstraction, which means more code, which means more bugs, abstraction leaks, complexity, etc. > couldn't the blame of bugs be moved to the business analysts writing the requirements? Shifting blame is just avoiding responsibility. Someone still has to be responsible. If what you're proposing is that the BA has to shoulder the expertise of formulating requirements, implementing them, testing them, etc, at some point an organization with half a brain will just hire different people for each responsibility. > if the code does exactly what the business requirements say People write tests precisely because code doesn't always do exactly what the requirements say (especially over time, as requirements change and technical debt mounts). > that could very easily fit into the plain English This is the old story of "make me a toast". Well, actually, that means opening the bread bag, getting a slice of bread out, putting it in the toaster, making sure it is plugged in, tweaking the timer knob, starting the toaster, waiting, taking the toast out, putting it on a plate, etc (never mind you have to actually buy the bread if you don't have any on hand or wash the dishes if you don't have a clean plate). Similarly: "make me carousel". Well, actually...
    - MuffinFlavored 8y ago
      > to shoulder the expertise of formulating requirements, implementing them, testing them, etc, at some point an organization with half a brain will just hire different people for each responsibility. So, in a perfect world, formulating the requirements would be implementing them with this "compiler/language/abstraction layer". Does that help make it any clearer?

lhorie 8y ago

Even if you assume programmers are replaceable code monkeys, you seem to be ignoring a large portion of what their responsibilities involve: fixing bugs, writing tests, integrating 3rd party libraries, managing version control, etc. Simply changing from programming language to one with a different target audience isn't going to make those responsibilities go away; you'd just be pushing them to people who don't necssarily have the skillset to translate a requirement to the highly strict format that a programming language provides. Your idea is analogous to saying "if only I created an amazing enough 3D printer, architects would no longer require engineers and construction workers to erect a building". But this ignores the fact that an architect doesn't know the first thing about bylaws, material strength, logistics, rain, etc. In reality, now the architect would be responsible for having the expertise of one or more other prefessions.

MuffinFlavored 8y ago
> fixing bugs I like this counter argument because as a developer, it stinks tracking down bugs. In a perfect world, if the English to code compiler worked pretty well, couldn't the blame of bugs be moved to the business analysts writing the requirements? > writing tests if the code does exactly what the business requirements say, why are tests needed? > integrating 3rd party libraries a huge portion of programming to me is "calling a function or an endpoint of a 3rd party library". to me, that could very easily fit into the plain English format I'm proposing for this "technology language"
- lhorie 8y ago
  > if the English to code compiler worked pretty well, "In theory, theory and practice are the same. In practice, they are not" In practice, the so called "english to code compiler" is an abstraction, which means more code, which means more bugs, abstraction leaks, complexity, etc. > couldn't the blame of bugs be moved to the business analysts writing the requirements? Shifting blame is just avoiding responsibility. Someone still has to be responsible. If what you're proposing is that the BA has to shoulder the expertise of formulating requirements, implementing them, testing them, etc, at some point an organization with half a brain will just hire different people for each responsibility. > if the code does exactly what the business requirements say People write tests precisely because code doesn't always do exactly what the requirements say (especially over time, as requirements change and technical debt mounts). > that could very easily fit into the plain English This is the old story of "make me a toast". Well, actually, that means opening the bread bag, getting a slice of bread out, putting it in the toaster, making sure it is plugged in, tweaking the timer knob, starting the toaster, waiting, taking the toast out, putting it on a plate, etc (never mind you have to actually buy the bread if you don't have any on hand or wash the dishes if you don't have a clean plate). Similarly: "make me carousel". Well, actually...
  - MuffinFlavored 8y ago
    > to shoulder the expertise of formulating requirements, implementing them, testing them, etc, at some point an organization with half a brain will just hire different people for each responsibility. So, in a perfect world, formulating the requirements would be implementing them with this "compiler/language/abstraction layer". Does that help make it any clearer?