On the contrary. Every engineer is able to learn the process when it matters. And it often does. The type of steel used, the treatment and the orientation is imporant to the outcome. You can not hand wave them away as "implementation details".
I don't see this is a disagreement with the GP. You say they (all engineers) can learn it, GP says they (few engineers) could tell you how it's done. Those are in perfect agreement. At any moment in time, there is likely no engineer who can explain fully every process used by their domain or object created by others in their domain. That doesn't mean that the majority of those engineers couldn't learn any arbitrary process or the details of an arbitrary object in their domain.
Of course not. A basic understanding? Absolutely, yes.
It's even widely accepted to be an important part of the education.
Just as Karnaugh maps and parser theory is part of computer science engineering curriculums. It's not something that's expected to be used a daily basis but some general knowledge of how a processor works is absolutely necessary to be able to at least talk about cache line misses, performance counters, mode swaps etc.
One issue is that the divisions between engineering fields are somewhat arbitrary, and technology doesn't always respect those divisions, so we don't know in advance what education is going to be needed. A second problem is that we make it very hard for young engineers to maintain their technical chops when they can be quite busy and productive doing basic design. In fact, engineering students hear through the grapevine: "You won't use this stuff once you get a job."
As a result, the industry settles on an "efficient" way of managing issues that require depth or breadth, which has to have a few people around who handle those things when needed. That becomes a form of division-of-labor.
This is true, but perhaps a bit of a tangent to a parable.
I was merely reacting to the statement that most construction engineeers wouldn't know "how concrete is made". Most of them could tell you a thing or two about it, it's even in the curriculum. They are even expected to know about different preparations.
The idea that specialization doesn't exist is a bit of a straw man argument and not something anyone seems to argue.
>If you're minimizing challenge for your software engineers, you're making worse engineers over time
Or you're solving your current problems in the most efficient means possible, e.g. engineering. Minimizing one challenge frees mental processing power to worry about bigger issues. I couldn't care less how the memory paging in my OS works. I care about building features that users find valuable.
Such a needlessly extreme example, sometimes it might mean just working on the backend after doing nothing but frontend for your career, sometimes it might mean not assigning a feature of a certain complexity to the person you know likely grasps it instantly and assigning it to someone who you're less sure about but wants to do more. It can be just as much about figuring out and cultivating the potential of your workforce and that can create greater efficiency over time. There are certainly opportunities where this can be accomplished, because if everything is mission critical, business itself is doing something wrong. The amount of opportunity and the nature of such will vary across businesses, and perhaps an engineer may need to go elsewhere to search out further challenge. Your statement that "Minimizing one challenge frees mental processing power to worry about bigger issues" presumes a level of uniformity.
On the contrary, by not minimizing the challenges you are left with less productive engineers. The idea that tools etc should be written internally if hen they already exist is such a Byzantine way of looking at things. The only challenges an engineer should face should be the problem they’re trying to solve. If you’re building a SaaS you shouldn’t be worrying about rebuilding all the tools a project needs to reach conclusion.
Yeah, but this isn't the Olympics. If the same people are producing better quality work with less stress... Sounds like you're doing something right even if they are technically not learning certain things that aren't relevant.
