> 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.
> 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
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.
> 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.
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!
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.
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.
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.
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
[dead]
>>"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.
> 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.
"The first 80% is easy... it's the second 80% that gets you."
> 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...
>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.
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.
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.
How is software engineering not a domain? If other domains can be easily learnt, sure this one can too
> Domain knowledge can be learnt much quicker than how to apply good engineering principles.
What kind of domains did you have in mind?
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.
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.
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.
> 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?
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.
> 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
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!
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.
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.
Only if the domain is shallow and mostly digital.
Applied to real world complex businesses good luck.