"Since I left my job at Amazon I have spent a lot of time reading great source code. Having exhausted the insanely good idSoftware pool, the next thing to read was one of the greatest game of all time: Duke Nukem 3D and the engine powering it named 'Build'. It turned out to be a difficult experience: The engine delivered great value and ranked high in terms of speed, stability and memory consumption but my enthousiasm met a source code controversial in terms of organization, best practices and comments/documentation. This reading session taught me a lot about code legacy and what helps a software live long." Hail to the king, baby.

"You can't get around the fact that if the software works it has been engineered correctly because it's doing what it was designed to do."

It works...until it doesn't.

As long as it's limited to personal code, and the original developer doesn't care about how it's engineered, then maybe it doesn't matter to him. But if he's working in a corporate setting, some other poor sole will inherit that code and he'll be none-to-pleased to learn that the earlier developer completely disregarded code quality in his work.

"Also, your idea of what is 'well-written and structured' can be and is very different from what other people deem as the same. One huge thing you seem to be missing is that personal opinion plays a large role in making judgments about someones code. I know several great coders who are often times in disagreement about code-related issues."

Of course there are different opinions, especially with details that come down to different tastes. But ask them if they think the engineering doesn't matter at all as long as the end product works. The good software engineers I know are proud of good engineering.