While I'm sure some people just want to write code for its own sake, I've never met one. What I've seen is coders working in domains that vary in what is econom

While I'm sure some people just want to write code for its own sake, I've never met one. What I've seen is coders working in domains that vary in what is economical, coders who have varying understanding of exactly how much rigor is needed at any given time, coders who have quirks of personality that sometimes lead them down unproductive paths. Never have I met someone who thinks the code is valuable for its own sake. But they do misunderstand, or misapply their understanding of, the task before them. I wanted to make this distinction because it changes the approach to managing communications. And it isn't just coders. Sometimes a manager isn't going to tell a developer "stop trying to hard and just slop it out" because the manager also has a self image that doesn't involve shipping swill to their customers. And I do think sometimes it really is difficult to know exactly where to draw the line. What parts of the product need gold plating? Where is stress going to appear, what is going to cause unexpectedly annoying debugging? In hindsight you should have spent more time there, not here. Maybe I've been privileged to work with people who care about real things- I've spent my whole career in relatively small orgs. I've self selected for that. Actually, now I think about it, I do believe I've met (not worked with) someone who was very into the code for its own sake. This was at a research institution, using Haskell, where "experimenting with edgy functional programming" was, if not part of every project, certainly an accepted and deliberate part of the culture.