IMHO there is the biggest gap between the raw intelligence and software engineering skills (including good practices). So, it means that most of the code ends up as code-golf-style contraptions, incomprehensible for anyone else (including their future themselves).
Full disclaimer: I used to be that guy who liked "clever hacks". Now I try to make code readable in the first place (largely thanks to Python philosophy).
Later in college when we started doing more team projects, comprehensible code became much more important. No one had the time to understand someone's doubly-nested list comprehension. We just wanted to finish the project and get on with life. In this sense, I think the moment you read someone else's shitty code is the moment you realize that you need to write good code yourself.
Still, I'd say it was good practice and helped me think about code in different ways.
Of course, Kernighan's law still applies, it's just that the definition of "too clever" recedes with skill and experience.
I might just be dumb but I've been bitten so many times I'm dubious anything can be verified by inspection.
The most brilliant programmer I've ever worked with wrote hardly comprehensible code since they could understand other's code easily, so they didn't feel the need to write readable code because, in their word, "What do you mean you don't understand it? It compiles, it runs, it works, you don't need more than that".
I bemoan lack of nice chaining. Some libraries provide APIs that allow chaining, e.g. Pandas. In other cases, I often find JavaScript (map/filter) and R (dplyr pipe operator) pipelines nicer to read.
However, Python 's Zen of Python can (and IMHO: should) be adopted to other languages.
One grad student friend of mine traded me a case of beer for a Saturday of help on his code. It was some code to record spike timings in the olfactory cortex and also control valves (smelly research).
By the 12th nested for-loop, I gave him back the beer.
Less code-golf, more hackathon-style "one more copy-paste and it should work". It has some use cases, just readability or maintainability are not among these.
The problem was that once in a while you'd just get some garbled text on the screen.
Eventually I figured out why: Some of the sentence fragments were malloc'ed, others were returned from the stack. Once the description got over a certain number of bytes he was smashing his own stack. I say 'his' but the problem was introduced by an earlier collaborator.
Buddy, I really want to help you with this but I (much younger me) am not up for unwinding a use-after-free bug of this level of recursion. Good luck, I'm out.
On several occasions, and with lesser crimes, I've told the person something like "I think you are confusing yourself with your own code. I want you to change to meaningful variable names (stop recycling variables) and factor out a couple of child functions here, and here. If you still can't see the problem, come get me and we'll try this again."
Haha, no way. Grad students are poor as is. Drinking a month's beer budget in front of the guy would be bad, leaving him with that code was cruel enough.
Me?