...until someone has to work on someone else's overly clever "masterpiece". It's not so black and white and a tricky thing to get right and almost impossible to satisfy everyone's needs.
In an ideal world, developers care more about how their program works more than how it is written. But ya, unfortunately most people are working on applications they don't care about, so they get overly creative with code and tools.
Almost always, the "overly clever "masterpiece"" is unreadable because there is no proper documentation, not because the program itself is horrible. If you can't understand it because the writer didn't document it properly, shout at them for the lack of documentation, not for the unorthodox code style....
Workaday code should be documented so another developer can skim it in n minutes rather than spend n3 close-reading it.
If workaday code needs documentation for other developers to understand it to begin with, it needs a rewrite. Even if it runs great as code, people aren't computers and it needs to communicate it's purpose to both. Finding a showstopping bug under pressure in code like that is enough to make you want to put pencils though your eyes.
Others also seem confused— it clearly wasn't the best wording. Maybe the usage is more common in my regional dialect or something.
'Workaday' technically has two definitions: the first is something work related, and the second is something ordinary, common, or routine. Both definitions carry connotations of the other though. In this context, I'm referring to the everyday code that we write to solve most problems. I'd juxtapose this with unusual code working around really weird constraints or making up for a fundamental shortcoming or bug in a language or critical library which might require janky counterintuitive code.
I'm not saying not to document nor did I say that the program itself is inherently horrible. Often we're working on one problem which will having us jumping into a function we've never seen before. If I have suddenly switch context to read a bunch of documentation to understand someone's "creative" coding style, I will not be happy. Agree to disagree, it seems!
In an ideal world, developers care more about how their program works more than how it is written. But ya, unfortunately most people are working on applications they don't care about, so they get overly creative with code and tools.