It seems he have been writing code so clever and compact that he didn't dare to change it when it came to refactoring time:
> I’d take any opportunity to write terse code. It feels good to be clever
> I noticed that when I wrote Python code, I would often go out of my way to avoid messing up a beautiful terse set of lines by moving logic to places other than where it might naturally belong.
I can see how a less expressive language might help with this problem, but I think a better solution would be to rein in the cleverness and focus on readability rather than shortness.
I think it's related to the iron law of abstractions. It's easier to change code that has no abstraction than the wrong abstraction. The right abstraction is better than both those, of course, but is often difficult to identify upfront.
Succinctly put. I have observed a tangentially related correlation:
The code that needs least understanding to change will be the code changed, until it isn't the code needing the least understanding any more.
In unison they sort of tells us why pragmatism is often good when we start writing code, but how we must always try to push towards finding (good) abstractions as the work progress.
> I’d take any opportunity to write terse code. It feels good to be clever
> I noticed that when I wrote Python code, I would often go out of my way to avoid messing up a beautiful terse set of lines by moving logic to places other than where it might naturally belong.
I can see how a less expressive language might help with this problem, but I think a better solution would be to rein in the cleverness and focus on readability rather than shortness.