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