You Should Write Ugly Code

Considering his examples, it's not. It's about architectural quality.

Indentation style is meaningless in this context.

Thanks, "Technical debt" is the word here. "Beautiful" might not come close to "valuable" in terms of importance, but "Clean" should come close, because accumulating too much crap makes maintenance & feature addition painful. Uncle Bob's "Clean Code" does a great job at detailing that.

beautiful code does work in shipping products. This article is just designed to stoke a flamewar. :/

I don't really like the casual acceptance of the total dichotomy between dirty and clean code here. I'll freely admit you don't always get to clean every bit of code and make it pristine, but on the other hand, with only a small amount of effort and perhaps 5ish years experience it becomes pretty easy to pump out clean-ish code at the same rate you can make an utter, total mess, and recover the value of your slightly higher effort in as little as a week or two, a time frame all but the craziest start ups should still be caring about.

Being in a hurry may be license to be "a bit sloppy", but I think it's a mistake to give yourself license to make a total mess, and use your speed as an excuse. For instance, once you're skilled at programming, and assuming you're using a decent language (another thing your startup should be doing), it's at most only slightly slower to refactor something into a function that copy and paste, and that probably still wins on every level the fourth time you reuse a function like that. Well-done unit testing can also have a payback time frame of under a week, in my opinion. You get bigger wins from listening to it guide you through the initial design that you will get from adding it later.

I had a really great post for this topic about the utility of ugliness in language design. Ocaml provides imperative features but makes them ugly, subtly encouraging a functional approach in most cases. Clojure quite brilliantly makes OOP and heavy Java interop possible but very ugly (because the language's ultimate goal is platform-agnosticism) while making idiomatic Clojure beautiful. Making something ugly is often more powerful than saying "don't do that". So ugliness has a real value, and that's what I originally came here to talk about.

Then I read the OP, which had to go and ruin that by being wrong.

First of all, OOP is not "beautiful". Quite the opposite, I find Delegates and Factories and Visitors to be fucking atrocious from an aesthetic perspective. All that stuff is there to make business people think their metaphors apply to code and to give them a sense that they, the "big picture guys", have a chance at understanding what's going on. They don't.

I've taught. I've designed games. So I understand the importance of aesthetics in any replication process. Making something easy to learn, understand, replicate, use, et al actually comes down to aesthetics. Now, it's a specific kind of aesthetic sense you need. You spend more time on convergent creativity (trimming, simplifying) than on divergence (adornments, gargoyles, "neat" advanced features). You should, at least when you start, ship a simple product that people can use rather than a complex one that you (having grown up with the complexity as it emerged) find "beautiful". With that I agree. It's better to write straightforward "boring" code that works than to apply every programming trick in the book (self-modifying code! three-level syntax quoting!) If the dumb thing works, use it. Complexity will happen on its own, so don't go looking for more.

Not paying attention to code aesthetics and simplicity, however, is a recipe for disaster. If your code is going to be read by other people and you write ugly, unmaintainable code, then... well, good luck with that.

I don't really mind the substance of what the OP is saying (focus on solving problems rather than writing code) but the presentation is awful.