[vinceguidry]

You should always let something else 'drive' your coding. Lots of people like tests. I personally am not a huge fan of TDD, though it's better than a lot of alternatives.

Essentially, you set a visible goal. Passing test, compiling program, running command, visible widget on a browser. Run the test / command / browser URL and watch it fail. Let the error message you get determine your next step.

It makes a good debugging workflow too. The first step is to get a reproduction. Then you need to set up an environment where you can repeatedly and idempotently reproduce the bug at will. Then all you have to do is keep trying and learning things about the system until you know enough to devise a fix. Here you can manipulate the command itself to exercise less of the system, giving you a clearer idea of where the bug is.

Whereas if you're building a new feature, you want to keep the command static until you see what you want to see.

There's nothing magic about programming languages or paradigms that allows you to do this more easily. It's just how well you know your system. Some domains are trickier. You need special tools and expertise to reproduce network errors, and God help you if your stack isn't memory safe.