"making your work easy to understand and explain to others"

This is the hallmark of a professional (very likely mature and senior) team member. Nothing to prove and interested in a maintainable project.

There are times for clever, no doubt. Every rule has an exception.

Bill (William) Kennedy at Ardan Labs has a line he uses in his talks: the bottom level developers need to grow and come up and the top level developers need to avoid cleverness and come down and everyone meet in the middle.

Look bud, not all of us want to take delight in being an easily replaceable automata. It ain't a personality flaw.

So you’d take joy in making your coworkers’ lives hell instead?

I understand the kind of joy-of-expression that lives in things like https://poignant.guide/dwemthy/, but if you attempt to put that in a production codebase, I’m not gonna be at-all positive in code review.

Great, I'll let every reviewer of my code know that they've been doing it wrong.

Are you saying that you actually write the kind of code that I linked? Because my expectation was that you’d look at it and say “well, my code certainly doesn’t look like that. It’s quite reasonable in comparison, in fact.” I don’t think I’ve ever seen anyone write code like Dwemthy’s Array in a project that has to “do something productive”, even if they’re the only one working on it.

Maybe the sort of code you linked isn't the sort of code we're talking about? Nobody is running around bigco writing demoscene stuff or whatever.

Doing the things I said well makes you an irreplaceable member of a team, worth your weight in gold.

Save art for the canvas, for your weekends, for your loved ones. Bring a professional self to your job.

Not sure why you seem to think code written with feeling behind it is some unmaintainable mess. That's been the opposite of my experience.

The way people fail in this line of work, if they have skill, is burnout. Burnout is the thing that'll get you. So you do whatever you can to stave it off - and that requires working on something you actually care about in some way.

We aren't talking about "code with feeling behind it" but rather "code as some kind of art".

You might have a different idea of what art looks like. Well designed abstractions are elegant, conceptually simple, and not-leaky. These tend to make code more maintainable and easier to comprehend.

One of the things you learn after writing code long enough, is that there is no such thing as a perfect abstraction, or even a non-leaky one. Eventually you run into edge cases, either in performance or functionality, that causes you to add warts to your abstraction.

Stipulating that no abstractions are perfect shouldn't be an excuse to abandon the entire notion. There's still a gradient of more or less elegant and flexible abstractions.

This definition of art, though not wrong, is so expansive as to be meaningless, especially in the context of this discussion.

> Take joy in doing these things with precision and efficiency, and making your work easy to understand and explain to others.

If you think this is different than what the parent is describing then you’re doing it wrong

"Code as art" implies a strictly different set of criteria than the ones I listed. If the Venn diagrams overlap a lot for you, that's great, but it's rare.

I think you have a very specific, and not widely shared, definition of “code as art.” Code as art does not mean code full of pointless Rube Goldberg mechanisms or following some esoteric golden ratio whatever. For me, “code as art” means code which is well-abstracted, readable, correct, concise, maintainable, extensible, well-documented, performant, etc — I.e. reflecting the things that matter to me as a developer. The process of getting to the point where the code has all of those things, or as many as possible, is indeed the “art” of coding. To assume that the result is some horrible morass of spaghetti that no coworker wants to read is a strange one for sure.

The thing I detest about discussions of code aesthetics is the idea that the quality metrics you speak of have such a direct relationship to the "product features" of the language, that we can simply know it's good by looking at it, and we are hapless simpletons unable to write this so-called "beautiful" or "clean" code if we do not have the feature available. That is all bullshit. Most of the features are shiny baubles for raccoons and magpies, I do NOT know what good code looks like(I can only state whether the coding style eliminates some class of errors), and what matters the most is the overall shape of the tooling.

Some languages have a big bag of tricks, other languages let you extend them to the moon, and still others make you work at it a little. In the end it's all just computation, and the tool choice can be reduced to a list of "must haves" and "cannots". If you need more expressive power -- make your build a little more complex and start generating code, give it a small notion of types or static invariants. It only has to generalize as much as your problem does, and that leads you to build the right abstraction instead of dumping an untried language feature on the problem in the hope that it is a solution.

Your definition of art is essentially synonymous with good or elegant, and therefore not really useful in this discussion.

What is your useful definition of art that is useful in this discussion?