SHARE:
Uncategorized

Baseball Is a Game of Pixels

Flatiron School / 21 June 2013

The following is a guest post by Steven Brooks and originally appeared on his blog. Steven is currently a student at The Flatiron School. You can follow him on Twitter here.

When I started coming up with ideas for this post I began by thinking about my specific issues in the code I have written to date (12 days) and the concepts that would help with those issues. One of the issues I had was keeping track of all my methods/variables early on and trying to find where each method/variable was coming from and what information it was giving. I then wanted to see if I could come up with plugins for Sublime 2 that would paint a background color pasted behind each variable/method as well as where else it would be in the code, and that background color would stay there as long as you wanted. This is different than Sublime circling the words or phrases you click on. Eventually I ran this by a classmate who tore down the idea so I will not be writing about that.

Over Chipotle on Tuesday I was speaking to two classmates about some of the things I did as an athlete and baseball player and was telling them that it was amazing how many similarities there were between being a baseball player and a programmer. I’d like to introduce you to some of them:

It’s Not Boring

Baseball, like programming, seems to be doing the same thing over and over again, which is why people perceive it to be boring, but that’s really just to the untrained eye. In baseball, you play the game with the same rules each day and as a hitter you hit against a pitcher every day. But every day is a new game and again a new pitcher or set of pitchers. The same macro level things occur daily in games but the fine elements of the game change every day.

Programming is very similar where for the most part you are coding into a computer every day, but you are not writing the same code each and every day. Each day brings new tasks, errors, and goals.

Be Comfortable With Discomfort

Being the batter in the 9th inning of the ACC Baseball Championship Game with the bases loaded where your team is down by one run and the opponent has their best pitcher throwing against you in front of thousands of people is not comfortable. Period. Writing dozens of lines of code only to find out none of it works when you have a deadline in five minutes and you have no idea what the error message in Terminal is telling you is not comfortable.

Discomfort is part of the game in baseball and programming. As a baseball player I was at my best when I accepted these situations as part of my role and became comfortable with discomfort. The same goes for good programmers, they must be comfortable with discomfort and realize that creating code that doesn’t work as well as not knowing how to do certain things is part of the role.

Breaking Things Down

As I have learned first hand in my first twelve days as a programmer, programs have many many parts. The same goes for a swing in baseball. In a swing, there are many, many, many, many smaller parts that create the whole swing just as there are many, many, many, many smaller parts that create an entire program.

In both scenarios, the key is to break down the whole into smaller and more manageable parts so when something goes wrong, it is easier to pinpoint error. In baseball if a player happens to be lunging forward before he swings rather than trying to say the entire swing is a mess he may pick a smaller part in his swing. Looking at something like film could help the player pinpoint the smaller issue. Typically, if a player is lunging in the batters box then their is an issue with his head (interestingly enough).

This scenario arrises in code as well. If a programmer is trying to run code and an error pops up it would not be wise to suggest the entire program is wrong and throw it away. Looking at the error messages that come up will allow the programmer to pinpoint the issue down to a smaller aspect rather than the entire code.

Practice & Adapting

If you don’t use it you lose it. Yes, you do. Everybody wants to hit home runs, but you won’t even be put into the starting lineup unless you practice your craft and are always improving. If you are not always trying to make yourself better, you are getting worse and there really isn’t anything in between.

As programmers, the more code we write, the more familiar we become with things such as syntax, and the better we become at coding. You also won’t be able to make Facebook if you don’t know the basics and whatever else goes into making Facebook. Its just like the more batting practice a baseball player takes the better he becomes (in theory).

Both professionals also require adaptation. Ever since technology began to play in integral role in baseball players have had to adapt more frequently and in shorter times. The information the teams can get and store on individual players is astonishing. Every at bat I had starting in college was tracked to the “T”. Every opponent knew about each of those at bats and would pitch me a certain according to my perceived weaknesses. As a player I needed to adapt to those changes and work on my weak points. Once I got better at those first weak points others would arise and would begin the cycle again. If I was unable to adapt quickly, I would have been no good.

While improving on weak points in programming is important, it is also equally important to be able to move with the times. I say this as far an new languages, technologies, updates, etc. I am currently running Ruby 1.9.3 but I am willing to bet that soon I will need to use a newer version and quickly learn the differences in the newest version and be able to implement them. And after that I’m sure a newer version of something will have come out by then and I will have to repeat the cycle.

Playing On a Team

This was the most surprising of the bunch for me. My younger brother is a Computer Science Major in Loyola in Baltimore and from what I could gather from him, being a programmer meant there would be little interaction with others. Once I began as a student as The Flatiron School I quickly realized that this would not be the case, rather it would be the opposite. Being able to program as a member of a team was kinda the icing on the cake for me as far as becoming a developer.

Like in sports, working well with a team takes a certain skill set. So far, it has been much easier to work with a team of developers (my classmates) that it was to play with baseball players. In the environment I am currently in, all of us are trying to learn a new skill together, so it makes more sense as of right now that the members of the team are easier to work with.

There are some others things such as preparation and mentality that are very similar between the two. But there are definitely some surprising similarities if you ask me. Who would have thought these two people were so similar?

Also I wrote this post last night and after proofreading this I realized that my sentences are wayyyyyyy to long. Kinda like my methods.

Previous Post Using the Twitter API to Find People on Twitter Next Post