> 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

>>"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.

> 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 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.

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.