There’s a good idea in the article, but I’m trying to distill it into something I can use: I don’t think we’re bifurcated into two kinds, it seems more reasona

There’s a good idea in the article, but I’m trying to distill it into something I can use: I don’t think we’re bifurcated into two kinds, it seems more reasonable to say there’s a spectrum: at one end engineers are more predisposed towards the way a program behaves externally, on the the other side, an orientation towards quality of the internals. On a separate axis we have development speed/competency, and in practice that really becomes a budget to be spent on external or internal quality. A top performer probably has time to do both. Someone struggling won’t do well at either. I would hope that for a thoughtful, experienced and self disciplined engineer, regardless of predisposition, conditions would dictate their focus, such as: maturity of product, maturity of industry, importance of correctness (e.g. writing a database vs a CRUD app), and the goals of management.