What happened to the sports section

When I was a kid, sports was a treat.  My earliest memory of knowing about sports was the 1986 Mets world series.  For some reason, everyone was happy.  Everyone in the city was celebrating together, and I joined in, without really understanding why.  My second earliest memory was watching the Giants win the superbowl in 1990.  By this time, I knew what sports was, watched the whole game, and truly appreciated the win.

From then on, I would watch whatever games (baseball, basketball, or football) that I could.  If you missed the game, since we didn't have 24 hour coverage with ESPN, your only hope was to catch a few highlights at the end of an hour long news broadcast or read a recap of it in tomorrow's paper.  I loved those little morsels of sports.

Why did I like sports?  Mostly, because it was fun to play.  Sports was also an escape into an idealized life.  There were heroes trying to overcome obstacles ending in either heartbreaking defeat or jubilant triumph.  Things were clear and lacked ambiguity.

In the past few decades, sports has evolved for me.  Coverage of sports has gotten intense.  ESPN runs sports games and analysis all day, every day.  With the power DVR, these days I've been able to watch a lot of playoff basketball.  Since I don't care about watching games live, I can watch a 3 hour broadcast of a game in less than an hour whenever I have time.  This is achieved by fast forwarding through commercials, free throws, time outs, and time used for instant replay reviews.  This is awesome.

Analysis of sports is pretty great now too.  After I watch a game, I typically look through twitter for reactions.  As a fan, it's fun to hear others celebrating with me.  It's similar to the experience of watching a game with other fans, without the pain of paying for tickets or going through traffic to get to the game.  The day after a game, I could get a newspaper for a recap, but I also have a few sports blogs which will write a few articles on a game or nba podcasts to listen to.

Sports has gotten a lot more subtle and complicated.  A player used to be judged on merit and beloved for effort.  Nowadays, a fan cannot simply like a player anymore.  A fan must know the player's history, the player's stats and be able to argue why that player has a better salary structure than another.  Advanced stats has convinced us that we cannot even tell who the best players are just by watching.  We need experts to analyze the game and tell us who we should cheer for.

Even if you ignore stats, choosing a player to root for is still complicated.  Every athlete now has a narrative.  We no longer judge them solely on their performance.  We must delve into their hypothetical emotions, motivations, and psyche to conclude whether this player deserves praise or not.

The other day, a new story line emerged when an NBA player, Jason Collins, announced that he is gay.  I suppose that is news, and I hope that it reduces bias and discrimination.  But as a kid, it's not really the sports story I craved for.  As an adult sports fan, I couldn't care less that he's gay.  I'd rather hear about his defensive footwork than what he likes to do outside of the game.

How has sports evolved?  It was a treat.  It was an ice-breaker where anybody could ask anyone else, "Did you see the game last night?"  Now it's as complicated as picking stocks.  It is as emotional as any soap opera.  Its rules are as complicated as our judicial system.  It's players have gotten to be so physically superior to the average person that they scarcely resemble anyone I know.

So is sports better than it was?  I think it oddly takes more effort than it used to.  In the past, I watched every game or highlight I could and read every newspaper article I could find.  This often left me wanting for more.  Now, there's too much.  I don't have time to watch every game I have access to, read every newspaper or blog, and listen to every podcast.  I think the challenge is getting as much sports as I want, but not any more than that.

Sports has changed a lot in my life time.  I wonder where it will go in the future.

Chasing stack overflows

Recently, one of my programs crashed with a segmentation fault error.

For the user of a program, bugs and crashes are bad.  For a programmer, bugs and crashes are ok. Almost everything I learn is via bugs and crashes.  If I knew a better way to implement something, I probably would have done it that way in the first place.  Watching your program crash and burn or compute at a snail's pace is great motivation to write better code.  And making a code change that fixes your buggy program is a powerful way to learn.  One might call this Crash driven development.

Here are a few things I learned:
1. Get comfortable using debuggers and examining core files.  It took me a bit of time and mental energy to set up the debugger that by the time I wanted to analyze things, I was sort of already mentally checked out.  I took a look at the stack, I dumped some local variables and I kind of gave up.  Using debuggers should be as easy as opening text files and reading what is going on.  

It turns out the reason for the crash could have been found if I spent a little more time with the debugger.  However, I gave up too soon.  The reason I gave up was because I don't have much experience working with debuggers.  I figured I'd be better off just reading my code, running tests and going from there.  Unfortunately, the crash wasn't really reproducible on my development machine, so using the debugger with the crash environment saved was the way to go.

2. Prove the bug, before implementing a fix.  After some time hopelessly trying to reproduce the crash a coworker told me that the machine where my program crashed was set up with a relatively small default stack size*.  He suggested that I raise the stack size.  This led me to a whirlwind of reading and code fixes, and tests that led me to conclusions like, if I overflow my stack, my program will crash.  While that statement is true, it didn't really prove that the cause of my crash was a stack overflow.  I should have spent more time definitively proving the suspected cause of my bug was indeed the cause or not.

3. Ask for help.  One colleague suggested that I had a stack size issue, which wasn't the case. Another suggested that I refactor my code a bit to make it a little more clear what was happening at the time of the crash.  This second discussion led me to re-evaluating a different section of my code and somehow seeing the problem.  Even though the second colleague didn't see the bug, just discussing the issues with him led me to solving the issue.  I have no idea how the brain actually works, but somehow just explaining my bug to another person who just asks questions is enough to re-wire my brain to see previously before hidden problems.

Just as a final note, the cause of my bug was an off-by-one error.  I was reading from a dynamically generated set of data records that could have variable number of fields and records.  I was using the wrong bounds, and sometimes (only on one type of machine and sporadically on some queries) the program would crash.  The fix turned out to be just a one line code change.

*Whenever I face a problem I'm not familiar with (in this case, stack sizes and stack overflows) I  typically turn to Google to help me research stack overflows.  How can I reproduce one, what signs are there that I might be doing something bad, are there messages that will help me identify what is going on, etc ... Unfortunately, searching the internet for information on stack overflows has been rendered virtually impossible by the ubiquitous programming Q&A site, stackoverflow.