[gfodor]

For mature developers the choices here are not about innate skill but about tradeoffs. This blog post makes the error of projecting what is a multi-dimensional problem onto a single dimension.

You can have a pretty abysmal code base with beautiful design on top and amazing UX and be rolling in piles of money, and be perfectly aware that the code sucks but made the decision that beautiful code was not the priority or competitive advantage of the business.

[smacktoward]

I would go a step further and say that, at least in my experience, the code bases that have yielded amazing UX, piles of money, etc. are almost never beautiful. The code may start out beautiful, but once people start using it they start surfacing naïve assumptions, flawed designs, bugs, etc. And if things are going well business-wise there's rarely time or resources to fix those issues in a beautiful, comprehensive way (since maintaining beauty frequently means massive refactoring or flat-out rewrites).

In other words, beautiful code is code that nobody uses.

[jackcviers3]

To me, ugly code is code that gets the work done but at the price of too much complexity ( non-DRY, non-cohesive, spaghetti, callback soup ), not enough abstraction, too much abstraction, or too few quality control measures (tests). These things make it difficult to maintain any code.

In other words, ugly code is code that must be rewritten to be maintained. Depending on the innate complexity of my problem that can be an acceptable trade-off.

Beautiful code should also be easy to maintain; usually that means making each layer of abstraction as simple as it can be, and adding a new layer of abstraction to handle additional complexity.

In this way, I may write more new code to handle newly discovered edge cases or new features, but at least I am not rewriting old code to solve the same old problems plus the new ones. That gets old really fast.