[pkoird]

A good code, in my opinion, is written by appropriate selection of suitably contained abstractions. The problem with this, and the article does try to talk about it, is that for you to select appropriate abstractions, you need to know the "entire" thing. Which is to say, you need to have a knowledge of something that isn't there yet.

In other engineering disciplines like say civil or architecture, this problem is solved by using a good blueprinting paradigm like CAD layouts, but I find a distinct lack of this in software[1]. Ergo this advice which is a rephrasing of "know first and build later". But it is also equally easy to lose oneself in what's called an analysis paralysis i.e. get stuck in finding the best design instead of implementing a modest one. In the end, this is what experience brings to table I suppose, balance.

[1]closest I can think of are various design diagrams like the class diagrams etc.