I agree and will add in a few bits: although I will obey the language's idiom, in general, I like to keep the number of "things it does" per line of code to the minimum. Kind of an anti-code golf.
I also document (or comment code) when I am waiting for the flow to kick in. For me, the documentation starts at the appendices. One for input files or api source tricks or describing the input tables in a database. Another for the relevant outputs. Maybe a "justify overall design decisions" section. Just stuff someone would wish if they had to handle it in five years.
I wonder why people boast they can do ten things in one line. Less lines of code doesn't mean less bugs. The debugger just stops at each symbol instead of each line which I think adds to the cognitive load.
Documenting while waiting for the flow is like stretching before exercise. It gets you to that place :)
I got my experience/slaps by fixing my own code in the same codebase for more than ten years. I have empathy for the future maintainers :)
I have passed on at least a few codebases. Sometimes, people get bright ideas and just dump what's working to do greenfield stuff. This is why an ex-coworker recently wanted me to come back to braindump on something I finished in 2009. After I left, some bright spark wanted to start from scratch and now there are continual complaints when the previous thing just worked, aside from a per-semester update, which the software would nag you about, as new departments appeared and such.
On the other hand, I had an apartment-renting suite I had written get passed on to students. While it was written in Perl (a famously "write once, read never" language according to critics), because I did just one thing per line and had comments at multiple levels (a block header for each function, comments within functions, a changelog at the top), they called back and said it was the easiest thing in the world for them to convert it, despite not knowing Perl at all.
Although I had been programming for years and years by the time I took a FORTRAN course in high school, I had a particularly exacting teacher with a Ph.D. in Computer Science and he drilled us on how we would have to deal with the code of others, or our old code, or code when we did not want to come into work with a cold. Cleverness is held in reserve for data structures and algorithms, when you have no other options. He was very firm on that.
I also document (or comment code) when I am waiting for the flow to kick in. For me, the documentation starts at the appendices. One for input files or api source tricks or describing the input tables in a database. Another for the relevant outputs. Maybe a "justify overall design decisions" section. Just stuff someone would wish if they had to handle it in five years.