[rhizome]

I think software development is less guilty of this, because the usual refrain is "if they're good, they can learn the specific stuff on the job." So the industry (generalizing here) might not always hire for expertise, but it does clearly value having it long term.

I think this discounts how similar most of the code written at different companies is, the nuances determined by business rules that are established elsewhere in the org chart.

[munchbunny]

I think that depends on how you're looking at the problem. College hires, for example, don't usually come into the industry having clear Frontend/Backend differentiation, but they will probably pick one path (or have it picked for them) on the job.

On the topic of business rules though: I don't think it's just business rules. As engineers, we're much better at our jobs when we can internalize the customer mindset, and that takes time. I recently switched industries, and my ability to make architectural decisions is noticeably weaker because I don't have the long view of my problem domain yet. Some PM's like to think that they have that all covered (in my experience, that happens about 50-75% of the time), but even technical PM's don't spend that much time thinking about the architecture, so in my experience it still falls on the engineer to spend some time thinking about the what/why and not just the how.

I think that applies to MBA's too. Business often look pretty similar, but technical and industry expertise makes all the difference.

[datavirtue]

So true. I'm a data engineer but I have to understand the customer's problem so I end up getting trained on the specifics of certain engineering problems related to jet engines and I have to study technical manuals so that I know what parts and sensors are producing certain data and why under an array of conditions. I could get my job done without learning all that but it would slow everything down and I would generally be a pain in everyone's ass.