3 ms·

If the job is now being a promoter, how can you not see that it’s a low skill, low pay job anyway? There are a billion capable promoters in LCOL countries that

If the job is now being a promoter, how can you not see that it’s a low skill, low pay job anyway? There are a billion capable promoters in LCOL countries that can prompt as good as someone in the Bay. Might not be worth stressing so hard to be a promptmaxxer. Could just become a bus driver or some other skilled profession if you want to keep earning a living.

black_knight 1mo ago
I don’t think this is actually true, though. In fact, I believe the opposite. My experience with LLM assisted coding is that I need a technical hand on the steering wheel to get something workable out it. Otherwise, what comes out is a brittle, non-functional mess that only in the most tenuous way resembles what I had in mind. The job was never to type the code out. The job was always to take a problem in the real world, and shape it into a model which can be implemented in software. What LLMs do not do is to architect a system of suitable complexity to the scope of the problem. If you give a low skill worker the job of writing the prompts you will first get a prototype. Then a prototype with more features tacked on. Then a prototype with so many features tacked on that it breaks under its own weight. Software engineers know system design, and can adapt the system design to the scope of the problem. Are we creating a single piece which will eventually expand into a big system, we need to design completely differently from if we are creating a robust stand-alone thing, which just needs to do one thing and do that one thing really well. If anything, we will need stricter skill requirements for software engineers. Just because anyone can produce code which runs now, does not mean we should let anyone loose on creating the critical software infrastructure of our society.
- skydhash 1mo ago
  > The job was never to type the code out. The job was always to take a problem in the real world, and shape it into a model which can be implemented in software. "Typing" the code was never the whole job, and it can be the easiest part. But "the code" is very much the artifact that is used to generate values. It being correct and easy to maintain lower the associated costs and MAY raise its value. It being brittle and hard to maintain raise the associated costs and WILL lower its value. So being good at system design is how you target the first case.
- echelon 1mo ago
  > Software engineers know system design And the models won't ever learn distributed systems? You're basing your assumptions on the current status quo. The models only started getting useful in December, and so we just assume that's where progress ends? The models are coming for all aspects of software. Schema design, distributed systems, SRE, ... They're not going to stop getting better. Especially when so much value creation and cost cutting is possible. You assume the contraction of software engineering has peaked. I'm saying it's only getting started. The skills we have aren't special or particularly hard. They're just boring and mundane enough that they're only attractive to a certain subset of the population. Most people would die if they sat in front of a computer for as long as we do. The demand for our skills has outstripped the labor pool. That's why we've been highly compensated, not because what we do is difficult. The march of progress will continue, and it's a good thing. It might hurt us to no longer have in demand skills, but the world will be better off as a whole. The important thing will be knowing what to build and how to market it. That's a totally different skill.

black_knight 1mo ago

I don’t think this is actually true, though. In fact, I believe the opposite. My experience with LLM assisted coding is that I need a technical hand on the steering wheel to get something workable out it. Otherwise, what comes out is a brittle, non-functional mess that only in the most tenuous way resembles what I had in mind. The job was never to type the code out. The job was always to take a problem in the real world, and shape it into a model which can be implemented in software. What LLMs do not do is to architect a system of suitable complexity to the scope of the problem. If you give a low skill worker the job of writing the prompts you will first get a prototype. Then a prototype with more features tacked on. Then a prototype with so many features tacked on that it breaks under its own weight. Software engineers know system design, and can adapt the system design to the scope of the problem. Are we creating a single piece which will eventually expand into a big system, we need to design completely differently from if we are creating a robust stand-alone thing, which just needs to do one thing and do that one thing really well. If anything, we will need stricter skill requirements for software engineers. Just because anyone can produce code which runs now, does not mean we should let anyone loose on creating the critical software infrastructure of our society.

skydhash 1mo ago
> The job was never to type the code out. The job was always to take a problem in the real world, and shape it into a model which can be implemented in software. "Typing" the code was never the whole job, and it can be the easiest part. But "the code" is very much the artifact that is used to generate values. It being correct and easy to maintain lower the associated costs and MAY raise its value. It being brittle and hard to maintain raise the associated costs and WILL lower its value. So being good at system design is how you target the first case.
echelon 1mo ago
> Software engineers know system design And the models won't ever learn distributed systems? You're basing your assumptions on the current status quo. The models only started getting useful in December, and so we just assume that's where progress ends? The models are coming for all aspects of software. Schema design, distributed systems, SRE, ... They're not going to stop getting better. Especially when so much value creation and cost cutting is possible. You assume the contraction of software engineering has peaked. I'm saying it's only getting started. The skills we have aren't special or particularly hard. They're just boring and mundane enough that they're only attractive to a certain subset of the population. Most people would die if they sat in front of a computer for as long as we do. The demand for our skills has outstripped the labor pool. That's why we've been highly compensated, not because what we do is difficult. The march of progress will continue, and it's a good thing. It might hurt us to no longer have in demand skills, but the world will be better off as a whole. The important thing will be knowing what to build and how to market it. That's a totally different skill.