I currently practice TDD where I work, but this part seems weird to me:

> "Try not to think of the bigger picture and don’t start create classes you think you might need."

You don't need TDD for this. Even when not doing TDD, if you're dividing your work up at all, you will naturally achieve this. It's only when you're trying to build the Golden Gate Bridge in one giant go that you run into situations where you're over-engineering, over-designing, and over-thinking prematurely.

Divide your problem into subproblems and solve them one at a time, this leads to a natural growth in complexity and minimizes poorly conceived abstractions. You don't need TDD for this to be a good idea.

I like TDD, but I dislike how religious it is. Not every problem is best solved via TDD. It's a tool in your toolbox, not a life philosophy. A strict adherence to testing has done wonders where I work (and we test iOS apps, no simple feat in the current ecosystem).