[cassianoleal]

> The company is now hiring again for a few roles and domain familiarity is not a strong differentiator anymore. We used to list "Software Engineer - Area". Now it's just "Software Engineer" and the team assignment comes after the offer is accepted.

> Of course, this is good for brilliant engineers that never had the chance to get deep into the domain and now have better chances at getting a job, but it's also sad to think that other brilliant engineers that spent their lives collecting domain knowledge are now competing on the same lane.

If the author's vision of the future is correct, then competent software engineers are safe. Domain knowledge can be learnt much quicker than how to apply good engineering principles.

Engineers whose main competitive advantage is domain knowledge are probably not that brilliant at engineering. They might still find employment in other areas of the industry where they accumulated domain knowledge.

[hliyan]

> Domain knowledge can be learnt much quicker than how to apply good engineering principles.

There was an entire thread a week ago about how domain expertise has always been the real moat: https://news.ycombinator.com/item?id=48340411

[9dev]

And I'd still question it. The experience of just… knowing how a good architecture looks like without being able to really put it in words is what makes a good engineer to me. These people can pick up relevant regulations or industry terms and deliver value quickly enough.

[physicsguy]

> If the author's vision of the future is correct, then competent software engineers are safe. Domain knowledge can be learnt much quicker than how to apply good engineering principles.

I think this is true in some things and less true in others.

It's a pretty high moat getting into stuff like simulation software because the people working on numerical methods overwhelmingly have PhDs and it's a mixed skill set. Domain expertise here requires you to know maths to a high level. Even mechanical engineers often struggle here; it's often applied mathematicians and physicists turned devs that work on this stuff.

I worked on a fairly gnarly signal processing thing a while back that required bringing together knowledge of physics and software and maths and I found explaining it to people was tricky as their eyes glazed over at some point because their knowledge typically only covered one part of those.

[pyth0]

> It's a pretty high moat getting into stuff like simulation software

I'm currently working on a simulation/game about space and orbital mechanics. I have a lot of software experience, I know how to build large projects and architect my code, and I know how to to test the end result to ensure I'm getting what I want. But I also don't have a strong math or physics background. In my experience, Claude (Opus 4.6+) has had no issues writing any simulation or game related math code. And the key thing is, I don't need to have a PhD in astrophysics to verify interactively and visually that everything is working as I expect to. I just have an interest in space, and a basic understanding of the physics involved.

> it's often applied mathematicians and physicists turned devs that work on this stuff.

It's true that this has been the case, but I also would not have been able to implement what I'm doing now without these models (at least without dedicated a huge amount of time on learning all of the physics and math). So I think this domain specific knowledge is becoming less of a moat than people realize. At least that's my perspective on the specific area I'm working on, but I don't have a hard time believing it extends to other domains, provided there is ample information about them online to have trained on.

[mattbee]

How is "without being able to really put it in words" a mark of experience? Surely an engineer should be able to justify why an architecture should be arranged the way it is!

[whstl]

It's perfectly possible to put that sort of knowledge into words, but not in a condensed "recipe" that can be explained in a meeting, that will go into a single Hacker News comment, that will cover all cases, or that will satisfy LLM users looking for the easy way out.

Pretty much every area of knowledge is full of those. That's why people publish books, that's why people go to college or get PhDs, that's why people with experience gets hired.

[lanstin]

Somethings are true not because of one big cause but 10,000 tiny paper cuts. Trying to explain it all just becomes a laundry list where each problem seems solvable but really each problem is there at the same time and inter-linked in non-obvious ways. And the experienced person just comes across as a nay sayer who doesn’t welcome innovation.

[ceejayoz]

There are plenty of deeply skilled, experienced people (in all fields, not just ours) who struggle to explain that knowledge to others. Being a practitioner and being a teacher aren't the same skill.

[kloop]

You're not wrong that a rationale is required.

But the master knowing when to break the rules because of tacit knowledge without being able to explain it is a real effect

[lelanthran]

The justification could be "I've seen this movie before and it doesn't turn out well".

[jmyeet]

That's an extraordinarily rosy view of the future.

I'm old enough to remember the dot-com crash, specifically the years afterwards. In 2002-2003, the unemployment rate of software engineers was something like 40%. In fact, the only reason it wasn't higher was because of the number of people who had permanently left the field to become plumbers (or other trades).

I think this is going to be worse. In the dot-com crash, what really happened is that non-businesses got funded and it basically the capital markets ceased to function to a large degree. That's not what's happening now. Yes, huge amounts of money are going into AI companies but the change is more structural.

Other industries have gone through this. In the 1980s a bunch of industries were intentionally destroyed or offshored in areas that have never recovered. This has continuing social, economic and political impacts. I think people are being naive here thinking this can't or won't happen in tech.

[misswaterfairy]

> I think people are being naive here thinking this can't or won't happen in tech.

What would this future look like? Software developer salaries burrowing into the ground?

[jmyeet]

There will be a handful of people who make stratospheric compensation, a bit like we have now.

Everyone else will have extreme job uncertainty, getting laid off multiple times, losing compensation as a result (ie equity vesting) with compensation that at first stagnates and then starts to slowly decline in real terms.

A lot of the big tech companies will likely spend less effort on non-core activities. Think of all the things Google does. Anything that's purely internal will be gutted staffing-wise because it's the safest testbed for shifting the engineer-AI balance on teams before rolling it out further.

If you listen to non-tech people now you hear tales of applying for hundreds of jobs and getting no response. That will become more normal. What's worse is that AI seems to be to blame here. Companies all use the same AI ATS systems and I've seen allegations that candidate scoring gets cached for upwards of a year. So if the system happens to give you a bad score, literally nobody will see your application because you'll get filtered out before any human sees you.

I was watching a VC give a talk from some conference in France and the general sentiment is that no companies are being funded with teams greater than 5. Why? AI. So don't think you can startup your way out of this slump unless you're somebody who has the connections and CV to get funded anyway, in which case you might well have some of those stratospheric options anyway, at least for now.

[adam_arthur]

There's quite a large cushion for software salaries to decline before permanent structural unemployment were to set in.

It's not really feasible for "normal" businesses to hire developers at current salaries.

Tech companies will probably shrink in headcount, but all the non-tech kind of businesses can increase developer headcount.

Current Tech salaries are far above other fields while requiring (used to) significantly less training or time investment to get into.

Phase 1 is more likely that software comp will normalize with other professions, and more hiring will happen at the fringes rather than being concentrated in a few big companies.

[bluefirebrand]

> There's quite a large cushion for software salaries to decline before permanent structural unemployment were to set in

Maybe in some markets but in many places around the world software salaries already weren't that high. Or at least not really much higher than other white collar professions

[teliosix]

That isn't going to happen. To me what is going on is that no one really reads anything positive so there is all the incentives to write as hyperbolic + negative as possible to try to rise through the noise.

The reality is this all the standard lump of labor fallacy. I am not a software engineer but it is obvious to me at some point I will be using claude code or whatever to automate tasks. I won't be taking software engineering jobs, I will be using code to do what is done manually today that you wouldn't bother paying a software engineer to handle.

Today's software engineers will just be higher up the stack from me the same way they are today.

In 20 years, many of us will be working in sectors of the economy that don't exist today.

The idea we get something as powerful as AI and it doesn't create new businesses and sectors is just stupid.

Imagine telling someone in 1997 they are going to be getting deliveries from Amazon all the time in the mail. What kind of idiot would believe this? I don't even read that many books!

[NikolaNovak]

>>"Domain knowledge can be learnt much quicker than how to apply good engineering principles."

I'm not sure that's universally true. Good software engineers who are arrogant about easily acquired domain knowledge have been the downfall of many an ERP system.

There's SO much IT that's literally all about putting business rules into the system.

[cassianoleal]

> Good software engineers who are arrogant about easily acquired domain knowledge

This is a problem of arrogance, not of domain expertise.

Having worked in a few different industries, I'd wager that for the vast majority of them, a competent person can probably learn 80% of the required domain knowledge in under 6 months. For the latter 20%, as long as the person is not arrogant, they will seek help from colleagues who have been around for longer.

On the other hand, solid engineering principles will take 10-15 years of actually experimenting and learning in practice what makes a system resilient and durable.

[mindcrime]

"The first 80% is easy... it's the second 80% that gets you."

[cassianoleal]

No one knows 100% of anything. This is one of the reasons we tend to work in teams. Rely on your colleagues and you'll be fine.

[misswaterfairy]

> Domain knowledge can be learnt much quicker than how to apply good engineering principles.

Partially disagree. Broad-strokes domain knowledge can be learned quickly, but honing that domain knowledge with nuance and consideration for complexity, particularly for organisations that are unique and are not often thought of as 'software development houses', can take years if not decades.

Yet I still see (and code review) 'professional' software developers that don't follow good software engineering practice.

> Engineers whose main competitive advantage is domain knowledge are probably not that brilliant at engineering.

The same is also true of engineers without domain knowledge, certainly in my experience. Maybe we just got unlucky...

[enormousness]

>Domain knowledge can be learnt much quicker than how to apply good engineering principles.

Can it? I'm of the opposite opinion. You can improve methodology much faster than gaining specialized knowledge.

You can enforce and fast-track the former because it's a matter of approach.

The latter is subject to the person's learning affinity, capacity and availability at the time and can't be forced beyond reasonable facilitation. It also builds on itself, with the corollary that there's a much steeper curve early on.

[dchftcs]

The development and acquisition of valuable domain knowledge is a hard, risky, expensive and slow process. Because the valuable domain knowledge isn't yesterday's, it's today's and tomorrow's. In fields where domain knowledge matters, it is also deeply intertwined with engineering - you won't task Jeff Dean to develop Unreal Engine from scratch.

With that said, there are still many SWE principles that are not fully internalized or adequately practiced by domain knowledge experts, and that will remain the case as much as domain knowledge remains valuable, because software engineering is yet but another domain.

[Aurornis]

This same complaint comes up on the topic of generic coding interviews, although shadowed behind the bigger complaints about simply disliking them. When people develop domain expertise they want to use that as a moat around their job. They want interviews to focus on stories about the things they’ve been exposed to on their past jobs, not test their abilities.

If you’ve been lucky enough to get jobs that expose you to the right things then you have a big advantage when the interviewers are looking for those specific things instead of your generic abilities or potential. It feels nice because you’re competing against a much smaller pool of people.

Unless you are not lucky enough to have been exposed to those specific domains yet. You can be a great engineer and even someone who learns quickly, but if you can’t point to the lines on your resume that match the job description then nothing else matters when the interviewers are playing experience bingo with your resume.

The move to generic coding interviews changed that. It was no longer enough to say that you had exposure to a topic at a past job. You had to show your coding skills, too. It wasn’t enough to ride on your credentials any more, which was highly frustrating to the well-credentialed.

However if you didn’t have the exact experience then the world of job opportunities becomes much larger. The people I know who like coding interviews the most (other than the rare competitive programming enjoyer) are people who are highly talented but came from less credentialed backgrounds: They don’t have an amazing university on their resume, they had to work at some company you’ve never heard of in their small town, but they are great at programming and just want a chance to prove that so they can move up to better companies. They’re never going to be picked by a company that’s looking for exact domain experience, but as companies open up job listings to people without that exact experience they have a chance to prove themselves.

The other people who relied on that domain experience to lock other candidates out of the hiring process don’t like it at all, though.

[bob1029]

> Domain knowledge can be learnt much quicker than how to apply good engineering principles.

What kind of domains did you have in mind?

[bonoboTP]

That's the right question. I don't like this dichotomy between domain and engineering. It seems to come from people who just build different CRUD apps for mobile and websites for businesses in different industries and that's what they call domain.

Not like a webdev entering game engine design or a database engineer entering computer vision research, or someone working in embedded hard-realtime systems switching to making video editing GUIs.

[cassianoleal]

That's a fair question. I suspect highly specialised industries are harder (rocket and space, defense, nuclear, etc), but for things like finance (most of it, anyway) and retail, which IME make the bulk of the tech jobs out there, it's certainly nothing out of this world.

[clapthewind]

I suspect you're a junior engineer if you think that way. Domains (any) are deep, and require thorough understanding before you can have business or revenue impact.

[cassianoleal]

I do feel like a junior engineer sometimes. Funnily I didn't as much for the first 15 years or so, but the longer I go and the more clients I work in, the more I feel like it - and I find it refreshing!

I agree that domains are deep but rarely I'll touch all areas of the domain in any given role. As I mentioned in other comments, I don't have to know all of it, as there are other people in the business and likely within my team who:

- probably don't know 100% either; but

- know things that I don't

We work together so as a team we have as broad and deep a domain knowledge we can for the needs of our products and projects.

[cmrdporcupine]

This is exactly opposite my experience in my 25 year career.

The best people I've worked with were the people who learned the ins and outs of the business they were making software for, not the people who learned how to write code really well or read logs or learn software architecture patterns. Those people (and I've been one of those people) often go around looking for nails for their hammers rather than really focusing on the customer need.

It takes a really sharp brain to pick up and learn an area of expertise that has nothing to do with software development, and figure out how software development makes that domain better.

[oytis]

How is software engineering not a domain? If other domains can be easily learnt, sure this one can too

[epolanski]

Only if the domain is shallow and mostly digital.

Applied to real world complex businesses good luck.