Writing the code you want to see is all about making your code focused on the application's functionality, not on how you want to build it. Many times as developers we want to get right to writing the code, because we have some idea of how the application can be built. If we instead start by documenting what the application should do - via tests - we will write code that is focused on the functionality. Our code design will more closely model the functionality, instead of how we thought it should be built before we started considering what it would actually do from a user's perspective.
Create a short gist illustrating a place where violating this rule would cause you to write worse code.
In the web world, a classic example of this is choosing a front end javascript framework before you consider the application's functionality. For example, Angular is a really cool framework. It's super popular and very powerful. And I would really like to use it to create a facebook like button in the footer of my new website. So let me go ahead and put that in there. Let's make sure it works, so let me write some tests that validate it. But what do my tests look like? "Given I'm nowhere, when I visit the home page, I should see the facebook like button" or "given I'm on the home page, when I click "like", I should like this page on facebook". This says nothing about the implementation. It says nothing about using Angular to somehow manage this. In fact, the simplest solution is probably to go RTFM on facebook about how to add their like button. Or use AddThis (because we might want other services later, but we should probably wait for that requirement).
By coding first, then testing, we've added unnecessary weight and complexity to our web page that really doesn't get us anything, except a bullet point on our resume.