> Stephen King's opinion just makes me think less of him (King) although I'm also a fan of his writing too
This happens in software development, too: someone is so single-mindedly fixated on their own approach to building understandable, maintainable software that they can't recognize understandable, maintainable software built any other way.
I've seen something happen a few times with senior engineers who are being integrated into a team. It makes sense for their first task to be a fairly easy change in the best codebase, the "model" codebase where everything runs smoothly and there aren't any nasty surprises. You won't show them the cesspool codebase that causes all your problems until later.
So you give them the easy problem in the easy codebase, and they react like they've been dropped into the pits of hell. They might say, "Where's the dependency injection?" or "Oh my god, you're instantiating this object directly instead of using a factory!" or something else, depending on their taste. They don't see any sign of the techniques they would use to build maintainable software, so they assume the worst. You reassure them: we don't have any quality or maintainability issues with this codebase. It's fast, it doesn't break, everyone understands it, and it has absorbed every requirements change product has thrown at us for eighteen months, tripling in size in the process, without losing those desirable qualities.
At this point they have a choice. They can keep an open mind, see if what you're telling them proves to be true in practice, and maybe learn how a codebase can be understandable and maintainable without looking like they expect, or they can let their obsession with their own techniques be their final thought on the issue.
Obviously this is much more crucial for software engineers, who almost always work collaboratively, than for a novelist who works alone. A novelist with a track record of success doesn't have as many reasons to appreciate the techniques of other creators as a software engineer does.
This happens in software development, too: someone is so single-mindedly fixated on their own approach to building understandable, maintainable software that they can't recognize understandable, maintainable software built any other way.
I've seen something happen a few times with senior engineers who are being integrated into a team. It makes sense for their first task to be a fairly easy change in the best codebase, the "model" codebase where everything runs smoothly and there aren't any nasty surprises. You won't show them the cesspool codebase that causes all your problems until later.
So you give them the easy problem in the easy codebase, and they react like they've been dropped into the pits of hell. They might say, "Where's the dependency injection?" or "Oh my god, you're instantiating this object directly instead of using a factory!" or something else, depending on their taste. They don't see any sign of the techniques they would use to build maintainable software, so they assume the worst. You reassure them: we don't have any quality or maintainability issues with this codebase. It's fast, it doesn't break, everyone understands it, and it has absorbed every requirements change product has thrown at us for eighteen months, tripling in size in the process, without losing those desirable qualities.
At this point they have a choice. They can keep an open mind, see if what you're telling them proves to be true in practice, and maybe learn how a codebase can be understandable and maintainable without looking like they expect, or they can let their obsession with their own techniques be their final thought on the issue.
Obviously this is much more crucial for software engineers, who almost always work collaboratively, than for a novelist who works alone. A novelist with a track record of success doesn't have as many reasons to appreciate the techniques of other creators as a software engineer does.