[in9]

I have the exact same problem as you. The reason why I behave like that is always due to some sort of anxiety in finishing the task at hand, together with a flawed protocol to design and review it.

So what seems to help me is:

- slow down, more time equals more time to think

- write specifications as neatly as possible and review it with the requester (even if it is only your self, review it many times). The more bullet points (checks, and tasks) the better. (Come to think of it, the number of checkable bullet points in an specification may be a good proxy for how much you are thinking on corner cases and etc)

- write extensible tests, read some nice TDD books (I haven't done that myself, but having some canon way of thinking about tests, together with reviewing tests can help you)

- incorporate the expectation that there will be mistakes onto yourself, onto the client and into your planning

- practice practice practice

[bmomb]

I'm gonna start writing more, i giving myself more time to code and review.

Do you have any recommendations on TDD books?

[suls]

Hands down the best book. Plus the authors are really nice guys! http://www.growing-object-oriented-software.com

[kerberos84]

I challenge your best book with the book of Kent Beck (founder of TDD) https://www.amazon.co.uk/Test-Driven-Development-Addison-Wes...

[suls]

I was hoping someone would mention it! While it is a good book as well (and Kent Beck has many of them!) I tend to describe his book as 1st generation TDD. It certainly was a great breakthrough in 2002 but it misses some very good thoughts that only came later (and to give credit: probably only thanks to his book). So, GOOS for me is the 2nd generation of TDD. Especially part II is invaluable to give as a reading and thinking exercise for my new devs.

[theptip]

+1 for this recommendation, even if you don't buy into TDD after reading it, it also covers a lot of great OOP principles as well.