When I read this, I assumed you meant "I don't even think about heavily structuring and documenting my code". And my intuition (after 14 yoe or so) is that this is correct. Heavy structure for a greenfield area is a premature optimization. And comments are only for expressing what can't be expressed using code or other tools. I'd say if you need _heavy_ comments you've chosen the wrong tool for the job.
Then again, maybe I'm just not smart enough to anticipate the right levels of abstraction on the first go.
He is saying he developed structuring and documenting as a habit and now it is second nature and doesn't cost extra effort. And since he is the one maintaining the code and coming back to it he is the primary beneficiary and is doing his future self a favor with the extra details.
Comments
When I read this, I assumed you meant "I don't even think about heavily structuring and documenting my code". And my intuition (after 14 yoe or so) is that this is correct. Heavy structure for a greenfield area is a premature optimization. And comments are only for expressing what can't be expressed using code or other tools. I'd say if you need _heavy_ comments you've chosen the wrong tool for the job.
Then again, maybe I'm just not smart enough to anticipate the right levels of abstraction on the first go.
He is saying he developed structuring and documenting as a habit and now it is second nature and doesn't cost extra effort. And since he is the one maintaining the code and coming back to it he is the primary beneficiary and is doing his future self a favor with the extra details.
That’s pretty much it.
Also, these days, I tend to design “iteratively,” so the structure and documentation help a lot.
That’s not something I could have done in my yute.
I talk about the way I do code documentation, here: https://littlegreenviper.com/miscellany/leaving-a-legacy/