When it comes to software engineering work, one cannot deny a publicly agreed upon notion that there are many ways of approaching a particular set of problems.
One common group of engineers would create a TO-DO list of feature requests and grind its bullet points one by one, while a more abstract type of engineers would lay down a set of foundational "skeletons" of their codebase and then undertake the burden of solving specific problems on top of it later on. Meanwhile, there may be yet another group of engineers who would be willing to venture themselves into clever shortcuts by "hacking in" a treasure box of highly sophisticated programming tricks (which, from a solely pragmatic standpoint, is a pretty reasonable behavior for those who are convinced that their work is being underappreciated and therefore the only way in which they can possibly secure their jobs is to obfuscate their solutions to the point at which they are disposed to require long-term maintenance).
In the end, however, there is a sense of sympathy that is being shared among all categories of engineers - a sense that, no matter how you are approaching a problem, your mode of work is a result of trying to resolve a dilemma between the work's integrity and reputation.
The axiom, "The Devil is in the details", is probably the most strongly felt among engineers who often struggle to deal with technical debt, whose origins can be traced all the way back to one's initial lack of attention to details. And as a result of this, it is a general agreement among those who are sufficiently educated that the ability to pay attention to details is one of the most virtuous aspects which can be honored to be possessed by a professional engineer.
Sadly, an unappreciable state of things outside of this castle of intellectuals is that most people do not value the importance of resolving inner details at all. An average client would demand that there be a nicely streamlined conveyor belt, upon which a sequence of attractive-looking software features march one by one like 1930s' cartoon characters and get fed right into the person's mouth. Managers and marketing experts, too, are oftentimes not on the engineer's side due to the tempting perception that laying down a solid foundation of the codebase for the purpose of preventing the accumulation of future technical debt is not the kind of labor which yields results that are instantly recognizable by customers as well as investors.
Therefore, it usually takes a dignified sense of courage for an engineer to take care of subtle details in one's software product, despite the awareness that such endeavors are likely to pass unnoticed while those who are rendering the most superficial parts of it are deemed the most productive experts of the field. In the end, however, true engineers will understand that a nerd's inability to self-promote in such a way is a sacrifice one has to make in order to preserve the core integrity of the product.