I agree with the submission - fuck correct code, if it's not maintainable it might as well not be correct. I'd throw out correct but illegible code if it was bad enough - spend an extra 100% of time rewriting, and then 1% of time relearning, or spend an extra 20% of time re-learning the confusing code every time someone has to go back and look at it?
readable code is more likely to be correct, but correct matters a whole lot more than readable. How many times have you had to hack on JSON serializer internals or HTTP layer implementation details or database drivers or filesystem I/O. Probably never, and if you did take a peek, you would not be thrilled, because a lot of that stuff was written 15+ years ago.
readable code is a tool that good engineers use to arrive at correct code, especially in cases where we haven't iterated with the product owners enough to know what the correct logic is, or domains where the requirements are not well defined. But correct code is the goal.
This can also explain why some of the very best programmers insist on using category theory and monads even though it is infamously difficult for untrained programmers to read.
FWIW my perspective is large enterprise webapps implementing complex and poorly-defined business rules. Not like I'm doing linear algebra or device drivers.
