81–90 of 272 posts
> Domain knowledge can be learnt much quicker than how to apply good engineering principles. This is a particularly ignorant thing to say.
(Also, both might be out of reach of the current AI architectures)
I've had quite a few conversations and read many thoughts on the subject of job security in the software industry through the years. New technologies, various crisis and crashes, just age , incoming "hordes" of less prepared developers, or whatever. If I had to highlight the one thing all those conversations had in common it would be precisely this: I thought that having this knowledge would set me apart And it never…
It seems to me that knowledge doesn't always imply competence, but the lack of knowledge often very well explains incompetence. And, since the LLM is replacing the competence part without imprinting any knowledge on the one that wields it, it generates a lot of competent imbeciles that pass interviews and appear as though they not only do things, but know things as well. And once you reach that critical mass, sheeeeesh
The problem looks something like (not a real example): Type Z hours maximum A per day, B per week, C per month, D per year. E more hours than A is allowed every F weeks but no more than G per month and H per year. More than B is allowed... etc Minimum rest hours I per day, J per week, K per two weeks, L per month. More is allowed every 7.5 days unless it is full moon and maximum hours per day were exceeded at least 3 times in the last 82 days except from solar eclipses or if the Kings is married 12.5 years or if the employee gave birth in the last 472 hours.
My employer has software to make the schedules. It cant tell where shifting around shifts is possible but you can try do it and it will tell you why it isn't possible.
I was hoping to calculate if multiple shifts can be shifted around to facilitate someones day off. Sometimes it just cant be made to work but if people are willing and there is a hole you end up doing it anyway. (I've done a triple shift once because the coworker wanted to bring his wife to the hospital.) Employees earn undocumented days off... and then you end up with multiple schedules, the real one and the official one. Possibly extra copies depending on who knows what is really going on. This cant be the way...
Better just have modern laws that make sense in code.
"I'm finding LLMs also competent at explaining and giving advice on other domain stuff I'm totally new to, which I have cross-checked with Legal/Product Managers and is usually right." "Usually" is the keyword. Until it becomes "always" (counterintuitive for heuristic systems) or "almost always" some human experts will (/may?) be needed to babysit. P.S. "_are_ usually right" since they are "LLMs". Methinks running th…
"These AIs are usually right about things I don't know anything about" sounds like the textbook example of risky thinking though.
Earlier quoted context omitted.
> Nobody is suggesting we "replace labor" with LLMs. I take it you haven't been listening to what the guys at the AI labs have been saying? Plus that's what the whole article is about. I'm not sure how you could've missed that?
You could replace every software engineer on the planet with a perfect LLM tomorrow and it would not lead to mass unemployment-triggered riots. If you're talking about software engineering specifically, you're not correct. If you're talking about all labor, you're talking about something unrelated to the article.
Earlier quoted context omitted.
Surely you can judge people by results though?
measuring programmer productivity is notoriously difficult. Does james, who shipped 20 features without testing thoroughly provide more value? or does joe, who patched a security hole in that time and avoided disaster? what about jason, who facilitated communication between them, and kept the infra going so their changes could go into prod without issues?
The results will hopefully be a lot more tangible.
This entire section is backwards to me.
The current state of a lot of different domains I've been in is that they tend to center around 2-3 major, generic products that all get retrofitted to fit those smaller/medium-sized businesses. Now that the economics have shifted, it makes sense for those businesses to bring on software devs to build software tailored to their problem specifically.
And you can't compare copyrighting. It's a totally different field, with different goals and different time tables.
I've had quite a few conversations and read many thoughts on the subject of job security in the software industry through the years. New technologies, various crisis and crashes, just age , incoming "hordes" of less prepared developers, or whatever. If I had to highlight the one thing all those conversations had in common it would be precisely this: I thought that having this knowledge would set me apart And it never…
does it never? seems to me that people pay me precisely for my knowledge, learned over many years. The knowledge translates into action, sure. But thats like the old parable about a plumber being paid €150 for a 5 minute consult that involves turning a single screw. "i could have turned that screw!" the customer cries, ignoring that yes, they could have. But they didn't know to. I think perhaps the problem is instead…
I could theoretically learn everything about plumbing but would still rather call a professional for the peace of mind that it was done "correctly" and it the process goes wrong, I would have an instant fix instead of trying to go back and educating myself on plumbing more.
Could you consider that as part of knowledge? Yeah and also no. Because the knowledge can be copied and put into a LLM but legally a LLM cannot sign off on things like NDAs or take accountability like a human has to in these roles.
"I'm finding LLMs also competent at explaining and giving advice on other domain stuff I'm totally new to, which I have cross-checked with Legal/Product Managers and is usually right." "Usually" is the keyword. Until it becomes "always" (counterintuitive for heuristic systems) or "almost always" some human experts will (/may?) be needed to babysit. P.S. "_are_ usually right" since they are "LLMs". Methinks running th…
Earlier quoted context omitted.
measuring programmer productivity is notoriously difficult. Does james, who shipped 20 features without testing thoroughly provide more value? or does joe, who patched a security hole in that time and avoided disaster? what about jason, who facilitated communication between them, and kept the infra going so their changes could go into prod without issues?
We won't be programmers in this scenario. The results will hopefully be a lot more tangible.
