Yeah. This.
I think that sometimes people that 'more compact code' is what we mean be 'less code' and it's really not.
I think the differentiation is at the algorithmic level: it's not algorithm density, it's 'system clarity' that's key.
I find a nice rule of thumb is 'don't code two steps ahead'. Just because you may think you need to write a couple of 'duplicate lines' here and there, don't even bother abstracting for it. Wait until there's a few more.
Software people tend to outsmart themselves and build way ahead of what they need.
I think it's better to 'discover' the minutia of architecture than to plan, it all but the grandest elements.
An artists drawing a figure will 'sketch out the form' - that's the basic architecture you can do up front, but it lacks detail. The 'art' comes out incrementally piece by piece.
And the human aspect: it should hopefully read like English to a casual observer.
It also helps to think of it from a business perspective:
+ What the code does is an economic asset
+ But actual lines of code are a cost centre and an ongoing liability.