It’s a good idea to check your code by running it after just five or ten minutes of coding
Pushing-up code changes in small pieces makes it easier to debug before committing and allows you to realize when you’re approaching something in the wrong way before you go to far down that road.
It’s an easy habit to get into, just like saving your MS Word document often
In the beginning, it was because it was challenging for me to compile my code. I was unsure of the steps, so I’d code until I got confused and then I’d compile and get a bunch of error messages. Then, the corrections required were numerous and hard to find. The better way is to code for a short time and then run your code to see if there are any errors. I understand now that this approach – making one or a very few changes, then running it and testing – is the best approach and it will help you in many ways.
By changing only a little code before running it and testing it, you can isolate bugs. If you only changed one thing and you get an error, you’re likely to think of the problem before you even look at the code: “I think I left off a semicolon again”, or “Of course, I iterated over foo array when It should have been bar array”. You haven’t changed much, so even if you don’t already know the problem, it will be easier to debug, for sure.
You also have the benefit of getting clues that you’re taking the wrong route entirely and you need to go back to the drawing board, which isn’t so bad if you haven’t been on the wrong road very long. For instance, if the new class you’ve introduced doesn’t perform properly with your program, maybe you need to change the structure of that class. If you’ve been on a roll and coding under the premise that your class is properly-structured then you may have put in a lot of work since last running your code. Now you’ve got a lot of code to delete and a lot of time wasted. However, if you only coded for five or ten minutes and then ran it and realized the issue, you only need to delete that small amount of code, reflect on what you’ve learned, and begin again with a better-informed approach. This is called “failing fast”.
The failing fast philosophy takes advantage of the frequent feedback of working in small iterations and testing code often in order to isolate problems, identify them early, and correct the approach before going too far in the wrong direction. You also maintain confidence in your code, having the recent confirmation that it’s working as intended.
You’ll thank yourself
We’ve all been typing along on some feature and had a sudden scary thought like, “It’s been awhile since I ran this code. I really hope it’s okay.” You can do away with those concerns, make debugging quicker, get feedback from your code more frequently, and maintain confidence in your project by coding in small iterations and running it often. You’ll benefit in many ways.
