{"id":18,"date":"2022-01-21T02:18:02","date_gmt":"2022-01-21T02:18:02","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/twohandedtravels\/?p=18"},"modified":"2022-01-21T02:20:38","modified_gmt":"2022-01-21T02:20:38","slug":"the-good-habit-of-coding-in-small-iterations","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/twohandedtravels\/2022\/01\/21\/the-good-habit-of-coding-in-small-iterations\/","title":{"rendered":"The Good Habit of Coding in Small Iterations"},"content":{"rendered":"\n

It\u2019s a good idea to check your code by running it after just five or ten minutes of coding<\/strong><\/h2>\n\n\n\n

Pushing-up code changes in small pieces makes it easier to debug before committing and allows you to realize when you\u2019re approaching something in the wrong way before you go to far down that road.<\/p>\n\n\n\n

It\u2019s<\/strong><\/a> an easy habit to get into, just like saving your MS Word document often<\/strong><\/h2>\n\n\n\n

In the beginning, it was because it was challenging for me to compile my code. I was unsure of the steps, so I\u2019d code until I got confused and then I\u2019d 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 \u2013 making one or a very few changes, then running it and testing \u2013 is the best approach and it will help you in many ways.<\/p>\n\n\n\n

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\u2019re likely to think of the problem before you even look at the code:\u00a0 \u201cI think I left off a semicolon again\u201d, or \u201cOf course, I iterated over foo array when It should have been bar array\u201d. You haven\u2019t changed much, so even if you don\u2019t already know the problem, it will be easier to debug, for sure.<\/p>\n\n\n\n

You also have the benefit of getting clues that you\u2019re taking the wrong route entirely and you need to go back to the drawing board, which isn\u2019t so bad if you haven\u2019t been on the wrong road very long. For instance, if the new class you\u2019ve introduced doesn\u2019t perform properly with your program, maybe you need to change the structure of that class. If you\u2019ve 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\u2019ve 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\u2019ve learned, and\u00a0 begin again with a better-informed approach. This is called \u201cfailing fast\u201d.<\/p>\n\n\n\n

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\u2019s working as intended.<\/p>\n\n\n\n

You\u2019ll<\/strong><\/a> thank yourself<\/strong><\/h2>\n\n\n\n

We\u2019ve all been typing along on some feature and had a sudden scary thought like, \u201cIt\u2019s been awhile since I ran this code. I really hope it\u2019s okay.\u201d 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\u2019ll benefit in many ways.<\/p>\n","protected":false},"excerpt":{"rendered":"

It\u2019s 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\u2019re approaching something in the wrong way before you go to far down that road. It\u2019s an… Continue reading The Good Habit of Coding in Small Iterations<\/span><\/a><\/p>\n","protected":false},"author":12044,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-18","post","type-post","status-publish","format-standard","hentry","category-uncategorized","entry"],"_links":{"self":[{"href":"https:\/\/blogs.oregonstate.edu\/twohandedtravels\/wp-json\/wp\/v2\/posts\/18","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.oregonstate.edu\/twohandedtravels\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.oregonstate.edu\/twohandedtravels\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/twohandedtravels\/wp-json\/wp\/v2\/users\/12044"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/twohandedtravels\/wp-json\/wp\/v2\/comments?post=18"}],"version-history":[{"count":2,"href":"https:\/\/blogs.oregonstate.edu\/twohandedtravels\/wp-json\/wp\/v2\/posts\/18\/revisions"}],"predecessor-version":[{"id":20,"href":"https:\/\/blogs.oregonstate.edu\/twohandedtravels\/wp-json\/wp\/v2\/posts\/18\/revisions\/20"}],"wp:attachment":[{"href":"https:\/\/blogs.oregonstate.edu\/twohandedtravels\/wp-json\/wp\/v2\/media?parent=18"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/twohandedtravels\/wp-json\/wp\/v2\/categories?post=18"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/twohandedtravels\/wp-json\/wp\/v2\/tags?post=18"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}