I learned programming the traditional way, if you will call it that. Started with visual basic back in 2005 in high school. Having practiced Test Driven Development for about 6 months, I can speak to the difference TDD makes in coding performance. Skeptics out there cite various reasons TDD is not effective, or even if it is effective it will not be practical in the professional world. Here I will speak of my personal experiences before and after practicing TDD.
First off, I’d like to make clear that TDD is a tool. As with all tools, the user must use the tool correctly to make good use of it. Improper use of TDD can lead to ineffective, or even harmful coding. I am by no means an expert in TDD, but I can speak to the difference between properly used TDD, and improper TDD or lack of TDD.
One of the first things I noticed with practicing TDD is minimalism. TDD prompts us to code only what is needed to pass the test, and to test only what we need our program to do. Previously, when given a problem, my mind would get very creative and come up with elegant solutions that look cool and do fancy stuff to impress myself and others. But that process would take time, and then when I finally get to coding my imaginary solution, it may or may not work the way I imagined it. It is faster to just start coding, and let the solution make itself evident. You get to your solution faster, with less code than you thought you would need, and your tests assure you that your program is doing what you are testing for.
Another thing that stood out to me is consistency. During that time when my mind would come up with creative solutions, I may encounter same or similar problems but come up with a different solution each time. This may not matter much to the customer, but other developers (such as my future self, or other developers who will look at my code) will suffer the inconsistent code. It is true that there are many different solutions to a problem, especially in the world of computer programming. But TDD asks of us to get to the solution as fast as possible, and then make the solution as clean as possible. Those requirements limit the number of solutions we come up with, and help us focus our coding standard into a consistent pattern that we can be proud to show our future self and others. We will also save ourselves the time of reacquainting ourselves with code when most of it looks consistent.
There are many other points I can continue to talk about, but I can leave that for another time. It is my hope that new developers will recognize TDD as a valuable tool, and also keep in mind that tools are not magic bullets. Tools must be used correctly to get their full benefit.