[black-alert]

> People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive.

Your thoughts seem to be very subjective. I hope you don't write your code as naive as you wrote this comment.

I code for over 30 years now. It has always been my desire to write beautiful code that reads well, scales well, has no bugs and performs good. Does this makes me a vain imposter and not capable? At this very moment I am working on a total rewrite of an unmanageable codebase that was written by a very 'productive' guy.

[Udo]

Any paradigm can be formalized to the point of perversion. I think that's what the OP meant when they said that the hallmark of that group is how they obsess about standards and processes. The existence of cowboy-style code such as the project you're currently dealing with does not necessarily mean that the "process-over-results" people are in the right. There are many factors to consider, including the structure of the organization you're writing the code for. I don't think it's naive advice to suggest that people spend less time listening to vain role models, instead of actively working on their own skills in order to make better judgements in the future, which brings us back to the point put forward in the article: the way to mastery is through practice.

[rzwitserloot]

I think you and the person you're replying to are closer in opinion about what it means to write good, professional code, then your comments are letting on.

How I take the article, and what I think most in this entire comment thread agree with, are the following principles:

[1] code quality IS important. I define 'code quality' here as how many bugs are introduced to do a given feature, how resilient this code base is to requests for additional features/changes, and how easy it is for new hires to grok it / for you to grok it after a few months have passed working on something else and you've lost familiarity.

[2] Whilst it is important, it is not the only concern. In fact, a shipping product is MORE important. That's not to say that code quality isn't important. Any project that has deplorable code quality even if it ships is in trouble.

[3] So far the most effective strategy for producing code with high quality, is experience (that's subjective; my opinion. But I bet you share it). The best way to get experience is to write lots of code. In fact, writing code of LOW code quality should help MORE: The 8th feature request that comes in that initially sounds like a job of a few hours that turns into a weeklong exercise in frustration with stapled onto the end of that process another week or two chasing bugs - and maybe you learn something about where you went wrong in your code that powered the initial shipping product. This sounds like a much better way to learn these lessons than reading a bunch of blogs and listening to a bunch of presentations theorising about what 'beautiful code' means.

[4] extremes are bad. This more or less is already concluded by #1-#3, though. However, the 'beauty' extremists tend to present, blog, and in general act like they hold all the answers, more than the cowboy extremists do. That's entirely subjective opinion, of course. It's just my experience, and yours may well be different. But _IF_ it is indeed true that you're far more likely to run into a beauty extremist than a cowboy extremist, then it stands to reason programmers who are irritated by extremists of any colour will tend to exaggerate somewhat more on the _other side_ of the beauty extremists.

In the end it's a pendulum, isn't it? A presentation or blog post that comes across as authored by a beauty extremist probably was a capable, 'well adjusted' (in the sense that they would agree that shipping code is at least as important, and experience is very important) – but decided to exaggerate a tad on the beauty side to address some perceived notion that the audience's balance was too far towards the cowboy end of the spectrum.

Enough of those kinds of presentations, and a few are bound to perceive that the pendulum has now swung too far out towards the beauty end, and start exaggerating the value of the cowboy end.

[kilburn]

What I'm missing in this discussion is that, from my personal experience, people who are very result-oriented hardly ever write correct code. They tend to leave a trail of subtle, hard to find bugs (because foreseeing edge cases is one of hardest parts of programming and doesn't happen naturally while thinking about the happy-path) and poorly designed persistence structures (refactoring code is easy, but refactoring data is painful-to-impossible - you just can't retrospectively collect what you forgot to collect initially).

Of course both extremes are bad. I lean towards the perfectionist camp, so I actively seek to work with someone result-oriented. I've found this teaming to bring great results, where both my partner and myself end up happy with the outcome and fulfilled in ways neither of us would by ourselves (for me because I produce more givem the same time, and for them because they feel much more confident in the resulting programs - corroborated later by the much lower number of bugs found in them).

I know this is the case because I've been told many times by many different people (and most of them actively seek to work with me again afterwards if the opportunity arises).