Learning how to fail. In my opinion, one of the most important and crucial traits you could possibly ever have! Although many of the patterns covered so far have been essential, I think that learning how to fail is one of, if not the most important thing to take away from the different patterns. From my experiences, learning how to fail encompasses everything! Whether it be coding, hobbies, or anything at all. It is something that I have noticed very early, and it is one of the most crucial parts about my growth as a person.
To relate it to coding, like a few of the other patterns, if all one does is stay within their own box and safety, they will forever become used to their own skills. Hard problems might never be solved, even if the person is capable, and mediocre designs will stay mediocre. Failure is scary, but without failure, you can simply never know what you did is right or wrong. From failure, people are able to overcome their limits and grow! For example, there have been countless incidents where programming interns messed something up, like most recently, a Starbucks intern sent a out a test post publicly, and although I am sure they were worried, it is probably something they will never do again! These failures is what helps you grow as a programmer and coding, and it is so important to learn from these mistakes. In my experiences, if I didn’t mangle this project or mess up that problem, I think I would not be where I am today. I still have much to learn, but if I stumbled into one solution after another, I think I would be a very very poor programmer. By far, I have learned infinitely more from failure than I have from success!
Failure as a whole is not something that someone should be ashamed of, but something that someone should be critical of! If you fail, why did you fail! What will you do to prevent it next time, and what will you do if you keep failing! These are all important steps to learn, and as one becomes more familiar with each step, failure will become rarer and rarer. I personally don’t think anything can ever be perfect, but with enough time and dedication, things can come very close! And that is something that I believe everyone should strive for!
Tag: week9
-
-
For this week, well, I’ve become very interested in refactoring! Despite it being something that every coder must do no matter what, if I can make my life just that bit easier for future me, I want to do that! So, I did some more research and browsed the web to discover this website by MarnixKlooster! And… though the website is a bit clunky to use, it holds a lot of very good information!
One thing that stuck out to me is the concept of a refactoring hat! It is the idea that if you’re refactoring your code and you feel tempted to change the meaning of the code, don’t! So get that hat and remember to keep things intact when you start cleaning up!
For me, this was something that felt very important, since I often have a distinct issue where as I’m going back on old code, I realize that I could do something an entirely different way because of a new perspective. This often makes the code a bit better, but at the same time, I often change the functionality of it, so not only do I have to edit that one portion, but all the portions of my code! It isn’t that my code is too coupled together or that it’s rigid, but because my intent changed and this is hopefully where my refactoring hat comes in!
As noted in the website, a good way to recognize if you’re changing the intent of the code is to make sure that you are not rewriting Unit Test. If you’re refactoring and your Unit Test seems to still work without any changes, then that means you’re on the right track! But if you refactor and find that there are things you need to change in your Unit Test, you better put your hat on more securely because you’re past the point of refactoring!
This is essentially the concept of Rewriting vs Refactoring! To paraphrase MarnixKlooster, refactoring is cleaning things up, so you have more wiggle room when designing your code. In essence, making more design space! While Rewriting is creating code that meets new specifications and implements algorithms and data structures that are more efficient than the previous ones.
Though both of these seem similar, they are very different! From my understanding, Refactoring is like cleaning up your room, you know, sweeping it, mopping it, etc! But Rewriting is rearranging your room entirely! Move your bed, your table, add a new desk, all the little bits and bobs! Though they do seem similar, they are very different!
Bored Coding 