I don't think it's so much that they are that way innately, as we select for it then drill it in further.

For junior and even mid-level engineers, your performance is generally evaluated on checklists of mundane shit. Code is passably neat and organized? Check. Code has and passes tests? Check. Feature checks requirements boxes? Check, check, check.

I think I'm similar (wanting a mix of technical and business problem solving) but I feel like this is the minority of jobs - though I don't have a good way to identify this.

Especially at larger organizations, I've found that the dev role is very much of an "implementer", that your job is to take the design, spec, architecture and put it into place as close to the above as possible.

You're much less likely to be actually sorting out the why/how of the system.

I think it's a learned behavior, they were mainly talking about people fresh out of college who were evaluated based on "use the fastest algorithm for a mostly sorted set of data" type assignments. I worked with a lot of people with technical degrees who learned to think outside the box, but it seemed easier to teach technical knowledge to non-technical people than it was to teach technical people that they needed to change the rigid way of thinking that had been drilled into their head for 4 years.

Easier to teach the skill than the attitude.

>Engineering disciplines are some of the few degrees that provide you the ability to both directly solve other people's problems and have close customer contact

Douglas Adams made his career reiterating the cliche engineers do not communicate with the customer.