"[W]hen you get prostate cancer and the oncologist puts you into the IMRT machine to zap an area close to your gonads with a dozen different beams of radiation,

"[W]hen you get prostate cancer and the oncologist puts you into the IMRT machine to zap an area close to your gonads with a dozen different beams of radiation, you’ll probably find yourself hopeful that a professional wrote the controller’s software rather than someone who was always chasing the next hot thing in computing (and maybe never worrying about stupid dull things like documentation, specifications, tests, code reviews, quality control or that sort of old-fogie stuff)" +1 I think it may be helpful to extract a couple of more layers from the analysis model. Clearly software "engineering" has been confronting the expected (required!) transition from an art and craft discipline to a full blown industrial discipline, and in my reading, the OP is really (only) addressing the required mindset and the necessary changes in self-perception of the practitioners. Equally clearly, we are still confronting the transition and frankly are stumped by some very (very!) fundamental issues that need to be resolved before software "engineering" can be industrialized to meet the industrial scale demand for software. (Consider: data persistence and logical process impedance mismatch; concurrency; etc.) So, in my view, to argue uniformly against "passion" (we all know what it means: software geek born to code ;) based on a completely fanciful projection of the process of software development to the analytical test bed of a established, industrialized, nearly-scientific, discipline, such as any sort of applied physics (MechE, EE, whatever), chemistry, etc. is inherently flawed. Yes, you don't need (nor want!) "Fuck you" starlets with attitude in your engineering department. But that is precisely the type of personality that is going to be constructively useful on the road to industrialization of software development. Because it is the "passionate" geeks that typically produce breakthroughs, and that is what we need as of now. Once we have solved the conceptual problem of how to produce software as an industrial product, then would be a more appropriate time to focus on the ideal psychology of a "worker" in the software engineering industries.