As I work through this week’s daily assignments, I am struck by the realization of how much my past (practices, thinking, ways-of-doing) creeps into my present work; even though I am attempting to be careful to not let it do so. And yet, at other times, I became so involved with what I was doing that I left behind what I know to be good practices.

With the multi-directional ball exercise, for example, I resorted to logic that was more conditional in nature without first giving thought to how I might approach the problem in a different way. I didn’t ask myself the questions of whether the code cold be made simpler, more elegant, or more readable. Here I slipped into the mindset that I knew how to code this thing, could code it, and got the code working, and therefore I was done.

I experienced just the opposite issue with the refactoring exercise. I decided to refactor my house. Now, the house that I created was pretty sweet—nicely designed, with many, many, many windows, different colors, several different shapes including a quadrilateral. Now, this doesn’t make the best example of refactoring—it’s too complex. Yes, that’s the use to which refactoring is meant. However, for this exercise a simpler approach (a simple wireframe per Scott’s direction) would have made for a better experience. With this exercise I spent far more time than necessary, and beat my head against the wall. What I forgot here is that when you seem to reach an impasse it often is a red flag that something other than the code (or in addition to the code) might be an issue. I got started with the work, pushed my way in, and then got frustrated because the endpoint seemed to drift further and further away from me. Here is an example of where I should have stuck with best practices.

In a third example, Scott thought it would be a great idea if I tried to randomize the speed setting for the multiple balls project. Yes! What a great idea! I got this piece of code working, and it’s pretty cool, but I wrote more code than necessary to accomplish the task. The reason for this is that I brought former knowledge to the task and didn’t take the time to read the P5 documentation to see how the randomize function works with this language. The lesson here is use the coding language to do all of the heavy lifting for you. But, in order to do that, you must learn the language.

Reading Diana’s post I am reminded of the power of collaboration. In my first example I would not have given my code another thought without Scott suggesting to me that it could be better. I am also further reminded that no matter how much any single individual is everyone can learn something from someone else.