Test-Driven Development - Kent Beck

Write a test. Make it pass. Refactor. Repeat.

An old book, but still worth a read. Should you throw caution to the wind and design a system this way? Probably not. Is this a sustainable process for writing interpretable, correct code? I think so.

I've always believed that tests are you first clients. They force you to sketch out how you'd like to interact with the thing you're creating. They help you discover requirements that may have been missed. They help you feel the pain of bad design sooner - if something is difficult to test, it's probably not decoupled enough.

All of that is great. But I think the biggest benefit of this approach is psychological. It reduces anxiety by forcing you to do something. Even if it's a tiny step, you'll probably learn something, which will trigger another step, and on you go.

I've personally followed some version of this approach for a long time. I can't say I'm always great about it, but it's stuck with me, so that's something.

Just don't forget the Refactor step. That's really important.