In my past life as an "enterprise" programmer, most people at best paid lip service to doing the "Right Thing." Most code I saw was incredibly bad, written by programmers who knew they would switch groups or companies, or go into management, before they had to seriously maintain it. Programmers I met who worked in an "enterprise" were not into their work. Few of them knew of anything outside of their prescribed Java or sometimes C++, or followed anything new or interesting in their field. I could mention something like The Mythical Man-Month, or talk about looking up an answer in Knuth, and get blank stares. Explaining closures to all but a couple was like talking to a wall. This was at a top-tier company, in one of the most prestigious groups in its IT organization.

I think real experience and talent as a programmer shines in the ability to find a solution which is both correct and takes the same amount of time to write as garbage. This is not always possible, of course, but I would caution against coding without thinking about this trade-off.

In the case of the original article, the author cites the foreign key debate. Truth is, because reasonable and good programmers disagree on which is better, this is not even a good example of quick-and-dirty versus the-right-thing. If anything, it's an example of difficulties in storing data in traditional relational databases.