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!

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.

I really like the term "workday code". I always struggle for a concise term to use for this and now I have one! Thanks :)

Also, agreed on documentation though I didn't feel like diving into that one in my response.

you misread workaday

I don't think I did but I wouldn't know since you neglected to explain how.

EDIT: Ohhhh I see now :)

I googled it but didn't really see anything obvious -- what is "workaday code"?

Not your side project.

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.