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!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

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!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Whether a beginner starts out with a training course or isself-taught, the first step on the path to softwarecraftsmanship is finding a craftsman to apprenticehimself to.Pete McBreen, Software Craftsmanship, p. 96 So far I like this pattern a lot, and I feel it’s close to what I’m trying to do during my studying, my previous … Continue reading Find Mentors →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

To become truly good at programming is a life’s work, anongoing enterprise of learning and practicing.Ron Jeffries et al., Extreme Programming Installed This pattern from chapter three caught my attention, the quotes they used in the beginning of this pattern were nice and  sometimes we need something to remind us that the 1000 mile journey … Continue reading The Long Road →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to Benderson’s Blog with me, Ben Anderson. This week we are discussing what is quality code for programming purposes. I grabbed a blog post from the blog Simple Programmer written by Peter Grainger where they discuss quality code and what makes up quality code.

The blog begins with what you should know to write quality software and they recommend a book to read that will give the directions more precisely, then he writes a section that is pretty interesting called “What you don’t code is more important than what you do code” and he sums it up with “The more code you write, the more potential bugs you could introduce”. I haven’t thought about it that way but that line definitely makes sense. Then he goes into setting goals and targeting a persona, you got to set what you want and what your users want from what you’re making and making quality code for that software is a mixture of the two and you go to be precise as you can. A key paragraph in the post is titled “Define the structure of the software in as much detail as possible” This is an important part of quality code as being the most detailed you can be, the more you will, and other people will, understand what is going on with the software.

The last couple sections discuss a couple things that I have talked about in past blogs such as the more tests you do, the better your code will be and the less bugs you will have, also the more reviews you have of your code the higher the quality and the fewer of errors you will find in the code and you just got to maintain your code and make sure its readable for future users and even yourself.

This blog was very informative on the subject of quality code and provided a great insight on what the writer thinks the common coder should know to write quality code. For me, an up and coming coder, its great to know how to write quality code for my future colleagues that I will be working with. The more they able to read and understand my code, the easier it will be for them and I to cooperate and work together on projects that are boss wants us to complete. In my class we are writing quality code to be tested to see if it will pass and we are doing that in groups which will already help me work in a team environment. I highly recommend checking this blog out, I provided the link at the bottom of this blog so you can go check it out. Thank you for joining me this week on Benderson’s blog and I will see you next week!

Link: https://simpleprogrammer.com/quality-code/

From the blog CS@Worcester – Benderson's Blog by Benderson's Blog and used with permission of the author. All other rights reserved by the author.