August 2007

You are currently browsing the monthly archive for August 2007.

The best feeling as a coach is when one of your students has a great day. Yesterday evening was one of those days, and it means enough for me to be slightly late to work in order to write about it. There are three major components in cheerleading for a guy, throwing people around, throwing ourselves around, and yelling. Yesterday was a very strong day for our guys, to be called Big and Little.

Yesterday was Big’s day. He hit some amazing tosses with his partner, nearly getting to his next level of stunt. This was due to a HUGE improvement in technique for Big and I look forward to see how he does today with it. That wasn’t the limit to his success. He also strived in the second aspect of throwing oneself around, aka tumbling. He has grown faster in this area than almost anyone I have seen, starting from his level and really taking it up a notch. I attribute this to his incredibly positive attitude, and will power.

Little also had a good day, though he did it all on his own. His stunting was on par with his previous performances, but he was one of three people on the team to step up up and throw his tuck on his own. He landed all attempts cleanly, and was one of only three people on the team to attempt without a spot.

All in all, way to go guys. I can’t shout you out all the time (as the girls would get jealous j/k), but last night you really were awesome, and you deserve the credit.

When I went to UCA camp last weekend there were two new dances being pushed around:

aka, the Soulja Boy. And:

Check them out. They are fun.

Recently a friend and I had a conversation about the quality of programmers in the workplace. Without delving too deeply into the specifics (so as not to get anyone in trouble), we discussed various metrics for measuring programmers and how they perform. That conversation, along with a recent talk I heard about quality of code, leads to the conclusion that as systems get more and more complex in our society, quality of code, effected by the quality of programmers, will become a serious matter.

Firstly, lets talk about the breadth of programmers in this world. Programmers are just one shape and size. Their skills range from systems level programmers to high level web designers. Some programmers know assembly, others also know the intricate details of Photoshop. This wide range of skill determination make it very difficult to judge the “Quality” of a programmer. This gets further complicated by the fact that in order to judge a quality programmer, you need to judge the quality of the code/product produced. Much of this judging could be subjective. This is a conversation for another realm, and other people to handle. I just want to centralize this post on the conversation that happened between me and my friend.

The conversation arose around some code like the following:

if(state.to_upper() == "AL")

  print "Alabama";

elsif(state.to_upper() == "AK")

  print "Alaska";

.

.

.

elsif(state.to_upper() == "WY")

  print "Wyoming";

else

  print "Unknown State";

What are your thoughts on this code? Is it efficient? Would we consider this good code?

Well that depends on many different factors. As a programmer, my first instinct when I see this code is: WHY??? Why do you have to go through 100 lines of code to find Wyoming? As a programmer I see a hash. I see a one to one mapping set. That train of though, however, is limited, it does not take into consideration several factors that might crop up. From what I can see there are a bunch of factors that can determine how you write code, but in this example I really see three main factors.

  1. Efficiency: If you the environment that your code will be running on and you can test it, it may be significantly faster to use the above set of code than dealing with setting up a hash and using hash algorithms. Conversely, if you don’t know the exact environment, you may be taking a risk assuming this factor.
  2. Maintenance: If you are looking to write code that can be easily updated and modified, say for example we decide to add Costa Rica, to your list, is it simple and easy, and straight forward. While this is a simple example, consider if we need to add a bunch of items to our statements, the above approach might be better represented as a Hash.
  3. Readability: This is a tough one, because there is both a positive and negative of this code in terms of readability. One, it puts all your code inline, meaning that you don’t have to jump to another file to see where a bunch of values are defined. However this approach also eats up a ton of space in your file that you have to scroll thus making more difficult to understand.

Conclusion Coding is not always easy, and sometimes there is a tradeoff for what you decide to actually implement in your code. It best to try and consider why and for whom you are writing your code and that will help you make the best choices.

Its official, I’m now a volenteer assistant coach for the St. John’s Cheerleading program. I’m very excited to be working with such a wonderful program and team. I have been helping out a few practices prior to camp and I will be going to visit them (and my college program, Villanova) at UCA camp tomorrow.