I've found the authors proposed approach at the end of the article to be a very useful one, even if you're not using TDD. A very regular piece of advice I give to new developers is "breadth-first not depth-first" - i.e. write a whole function at a consistent level of abstraction before you dive into writing the other classes etc. you need to support those few lines of high level code.

I find that most new developers instinct is to do exactly the opposite - i.e. write the first line of their main function, then realise it needs, say, an argument-parsing class, so start writing that, then realise that needs a logging class, so start writing that, etc. which means you have to keep much more stuff in your head at once, you end up writing much more code in each commit than you should, and the distinction between bits of code at different levels of abstraction often ends up much blurrier which leads to messier design.

This seems to be quite easily countered though - just pointing out to people the difference between breadth-first and depth-first styles can have quite an immediate effect