It could be that whatever lackluster expertise you can squeeze out of an LLM is good enough to discourage investment in the real thing since unlike NP-complete problems, expertise isn't generalizable.

Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code.

Domain expertise is valuable and hard but I don't get this "domain expertise is harder than disciplined coding" mentality.

Not all code has to be efficient scalable code. I know some domain experts that were not programmers. They picked up enough Python or Swift + UIKit (this was pre-LLMs) and their applications are now widely used in their domain. In some cases, they contracted some software companies in the past to do the work. However, they did not understand the problem domain well, requiring the domain expert to iterate with them over and over. In the end it was more efficient to let the domain expert to learn enough programming do it with some guidance from experienced programmers.

Also remember that a lot of domain-specific apps do not need to be huge. E.g. I was once at a factory in the 90ies and they needed to do time-consuming calculations for a particular expensive machine. So, someone who worked at the factory wrote a small program in Excel + I think VBA. This accelerated their work extremely and probably saved them 10,000s or 100,000s in manual labor. It was easy for a non-programmer to write, because they knew all the details of the machine and the calculations, since they had done it over and over again. But it's not a enterprise web app or anything and it does not matter if the program runs in 1 or 4 seconds.

By the way, I also consider efficiency to be a specific knowledge domain, or architecting a very large project. So in the end it really depends on how narrow or wide your definition of 'programming' or 'coding' is.

I think there is some prestige factor in the background too. Being seen like some kind of code monkey is to be avoided like the plague. Business people really don't value the math savant engineer nerd archetype who just codes and codes.

Highest prestige is always taste and judgment, not correctness and skill. This is why people will also talk about how business soft skills, communication etc are more important than hard skills like programming, math, etc. I think one should be careful with this. On the one hand it's true that career progression is quite dependent on soft social skills, but there are also really hard kinds of software jobs where cognitive horsepower and technical experience are absolutely crucial and soft skills won't save you.

Programming is the easiest part! (c) decade+ experienced senior developers

Coding is way easier.

"efficient scalable code" is just as vague as good code. How are you going to know your code is scalable if you don't understand your domain? Scalability is not something you sprinkle onto code.

Sometimes you need two orders of magnitude. Sometimes you need five. Sometimes you need less than one.

Efficiency is about using minimum cpu cycles or minimum memory or minimum network round trip or more generically using minimum/optimum resources to get something done.

Scalability is about minimizing bottlenecks and linear scaling so one can just copy and execute by adding more nodes/resources and expect correctness and increased throughput.

Both of these have nothing to do with domain expertise.

But I'd also claim that these things fall on a spectrum. At the extreme end we have exchanges and HFT-like trading systems, where absolute accuracy and latency are not even constraints but industry fundamentals. At the other end we have "toy" applications that handle tens of requests per second, tops.

Scalability problems are definitely near the extreme end. Only instead of raw latency, you get to deal with complex failure modes, throughput, capacity problems, read amplification and thundering herds... all the while being constrained by available CPU cycles and bounded memory.

Yes, technically, but note that this entire thing can be anything from crucial to completely worthless depending on the domain.

You need insane scalability for a social network or a streaming service, you don’t need any real scalability for (completely made up) managing a fleet of airplanes or the internal logistics of a zoo.

No profitable business wants to pay you for writing code that uses "a minimum" of a resource. It wants to pay you to find the right balance between resource usage, time-to-market, operating cost, code complexity and probably several other factors.

This has always been true since the dawn of programming.

Whole TFA doesn’t take into account reason why software development was actually so valuable.

Single specialist in any domain is not that valuable. You may charge $200 for hour of his time sure. But to grow company you now need N specialists.

What software was doing was not making specialist obsolete replacing a specialist by encoding his knowledge - well many tried to do so but failed even in 80’s “expert systems”.

What software was doing was making it possible to structure specialist work, make it possible for a single specialist to serve more customers at the same time, make it possible to hand over work in a structured way to junior specialists, making it easier for senior to take over edge cases and spot check work of those junior specialists.

This setup allows company to not being tied to number of specialists to grow, this setup allows company to charge less per customer but take over more of the market share.

Whole premise that now each specialist will waste time dabbling in AI software development is ludicrous, especially if each specialist would be building his own tooling somehow.

Whereas in larger technology firms, yes that happens to some degree, but only with the highest level specialists such as PEs, fellows, etc.

They are already so wildly profitable and valuable by the simple nature of computing itself: it scales second only to money with regards to compounding effects. Once you have software someone can use, it scales near infinitely to more users, thus value is extracted from the work of a single specialist for all time. No need to complicate it with trying to abstract work juniors can do (and fail) and then have seniors correct. What would they be doing in non-extractive firms?

A SWE who has always worked in DevTooling companies will always be preferred by DevTooling companies over a generalist. A SWE who has always worked in AdTech will always be preferred by AdTech companies over a generalist. etc etc.

Software fundamentals - though useful - are table stakes skills at this point. No business wants to deal with the headache of on-ramping employees who have never worked in a specific domain or industry because it takes too long for a generalist employee to build the intuition needed to understand that segment of the industry.

I'm having a difficult time even seeing what we're talking about here. I see "seniors" in our industry that don't know what I would call the fundamentals of programming or software development; apparently not all fundamentals are created equal.

Historically, startups were the traditional path for a generalist to build domain expertise because most startups couldn't be picky with talent, but the market has changed.

In all honesty, too much fat did develop in the tech industry over the last 6 years. Traditional hiring pipelines (eg. Limiting early career recruiting to grads from top 10-20 CS/ECE/EECS programs nationally along with Vets and some grads from decent regional programs) still net good calibre talent worth their weight in gold, but others just aren't working out.

On the other hand, hiring a mid-career SWE who spent much of their career in one domain who is transitioning to another is a significant risk without additional social proof such as referrals where someone actually vouches for their skills.

The usual sickness. If you don’t train people to become specialists and just expect them to fall from the sky, it’s only a question of time until you run out of specialists.

Additionally, limiting early career hiring to to T10/20 CE/CS/ECE/EECS programs (they tend to graduate around 10K students a year), veterans (they tend to have the "can-do" and fast learning mindset needed), and a couple regional schools is more than enough to build a self-sustaining early career pipeline for just about any segment of tech indefinitely.

Chaining unrelated sentences is retarded. Chaining sentences like most people is common sense. Chaining sentences airtight is math.

You ask what a true mathematician does. He chains sentences like everyone else but with an effort to make them airtight.

Really?. Funny that everyone now knows US overclaimed their capabilities.

Iran alone is beating the shit out of US. Thinking it can steamroll Russia is not even funny. Some serious epidemic of Hollywood syndrome permeates the US.

And what has it to do with distributed architectures. You must not be good at what you do.

The important information was the US was able to rescue their people, loss of equipment doesn't matter. When we removed Bin Laden we lost an helicopter. Equipment loses that don't degrade our capabilities don't matter to the US.

There were ZERO American casualties in an operation in Iran, where the USA basically setup their own airfield, and Iranian forces tried to engage.

Buddy. That is not how winning looks like.

If casualty count is your criteria, then Soviet Union was defeated in world war 2 according to you.

If you think distributed architecture is about rescuing a bunch of people, then clearly you haven't done any serious work in your life. Go write some code and build some distributed systems.