4 ms·

I think this tends to overestimate the amount of time folks who aren't developers want to spend developing. Most spreadsheets, even of the complex variety, exis

I think this tends to overestimate the amount of time folks who aren't developers want to spend developing. Most spreadsheets, even of the complex variety, exist as steps in a chain of human decisions -- they basically replace notepaper and calculators. (Spreadsheets that act as inputs to software chains are usually created by developers.) Having previously been involved in architecting and building enterprise low-code/no-code solutions, and then working as a strategy consultant thereafter (including partnering with other major low-code/no-code vendors), I can say that what the business wants to do is sketch out the rough plan of how a process works (with a couple of exception states) and have someone else go through not only the implementation, but the hard work of dealing with all the error states, data cleansing and ETL, deployment, and monitoring, while they get on with the hard work of actually doing their jobs. There just isn't an appetite for people to do two jobs at once. What the article seems to miss is that companies are currently being much more aggressive in nearshoring work -- there's a huge boom in Mexico and LATAM development that's pushing up salaries there (as has happened in Eastern and Central European states). One thing that's distinct from the offshore boom is that, if you weren't a major consulting org, your offshore folks probably weren't colleagues, whereas with nearshore you're much more likely to see them integrated into the organization (again, due to TZ and the ability to fly someone in at the last minute for meetings). It'll be interesting to see what this does to the Mexican/LATAM economies -- Costa Rica, for example, with only $5mm people, punches way above its weight in software services exports.

josevalerio 5y ago
Couldn’t agree more with your second paragraph. A phrase that’s been drilled into me in the past year is “undifferentiated heavy lifting that’s not core to your business”. The things you listed just don’t matter from the business point of view. They don’t care how the app works, who runs it, what cloud provider is hosting it, what tools were used to build it, only that it works when it needs to and they will happily pay the bill so their employees can focus on making the company money doing what they are good at. Zack Kanter from Stedi talks a lot about this.
- sdepablos 5y ago
  We humans reject the concept of exponential growth, specially when it can kill our way of life, and in that sense developers don't realize that 80% of our work could be automatize in the next few years. I've been in the industry for more than 20 years now, and what's clear to me is that a lot of time is spent coding and debugging things that have been done previously plenty of times (Non Invented Here syndrome) and that in most cases are not core to our companies. What I expect it's not so much things like Copilot or AlphaCode (that of course will be used) but serverless services that we'd plug into our solution (how many more login services do you want to implement AGAIN?), like we do right now with APIs, but at a higher level, with a standardized communication protocol between these services. The same will happen the infra level, with only a few people creating and mantaining "low level" solutions while the rest of us will use abstracted services on top of that, like using Cloud Run instead of learning a massive APIs like k8s (I'm not saying that they're comparable right now, but at some point something evolved from Cloud Run will make learning k8s unnecessary) What will happen once developers are freed from the most time intensive aspects of their job? Probably and for a few years the unmet demand for developers will cover our increase in productivity, but at some point I expect this job will face some of the problems you can see in other sectors.
  - rightbyte 5y ago
    You don't need fancy AI to make us unemployed. Just back to basic would do. You list complex solutions which would just need even more programmers to maintain.
    - codegrappler 5y ago
      Was coming here to say this. Every time a more sophisticated system has been built to replace a simpler one, it requires MORE programmers, not less.
      - rightbyte 5y ago
        Ye. I think there is way to much "automation" nowadays. It is like all these business systems corparations use. They would probably be better off with some secretaries with typewriters sending internal paper mail. Systems that try to automate too much are too rigid to use in a sane way. The nice thing with a no computer system, is that if you want to do something, just do it. An analogue would be writing math notation on paper or on a computer. I can hardly imagine even Knuth prefering the later. Computers should be used for well defined tasks they are good at with rather simple programs, or the whole business need to adjust to what the computer allows.

josevalerio 5y ago

Couldn’t agree more with your second paragraph. A phrase that’s been drilled into me in the past year is “undifferentiated heavy lifting that’s not core to your business”. The things you listed just don’t matter from the business point of view. They don’t care how the app works, who runs it, what cloud provider is hosting it, what tools were used to build it, only that it works when it needs to and they will happily pay the bill so their employees can focus on making the company money doing what they are good at. Zack Kanter from Stedi talks a lot about this.

sdepablos 5y ago
We humans reject the concept of exponential growth, specially when it can kill our way of life, and in that sense developers don't realize that 80% of our work could be automatize in the next few years. I've been in the industry for more than 20 years now, and what's clear to me is that a lot of time is spent coding and debugging things that have been done previously plenty of times (Non Invented Here syndrome) and that in most cases are not core to our companies. What I expect it's not so much things like Copilot or AlphaCode (that of course will be used) but serverless services that we'd plug into our solution (how many more login services do you want to implement AGAIN?), like we do right now with APIs, but at a higher level, with a standardized communication protocol between these services. The same will happen the infra level, with only a few people creating and mantaining "low level" solutions while the rest of us will use abstracted services on top of that, like using Cloud Run instead of learning a massive APIs like k8s (I'm not saying that they're comparable right now, but at some point something evolved from Cloud Run will make learning k8s unnecessary) What will happen once developers are freed from the most time intensive aspects of their job? Probably and for a few years the unmet demand for developers will cover our increase in productivity, but at some point I expect this job will face some of the problems you can see in other sectors.
- rightbyte 5y ago
  You don't need fancy AI to make us unemployed. Just back to basic would do. You list complex solutions which would just need even more programmers to maintain.
  - codegrappler 5y ago
    Was coming here to say this. Every time a more sophisticated system has been built to replace a simpler one, it requires MORE programmers, not less.
    - rightbyte 5y ago
      Ye. I think there is way to much "automation" nowadays. It is like all these business systems corparations use. They would probably be better off with some secretaries with typewriters sending internal paper mail. Systems that try to automate too much are too rigid to use in a sane way. The nice thing with a no computer system, is that if you want to do something, just do it. An analogue would be writing math notation on paper or on a computer. I can hardly imagine even Knuth prefering the later. Computers should be used for well defined tasks they are good at with rather simple programs, or the whole business need to adjust to what the computer allows.