I love Noah Veltman’s visualization of the changing height and weight distribution of professional football players. It uses animation to convey the incredible increase in size of the typical football player, and it does so with a minimal amount of chart junk. Let’s look at two aspects that make this effective.
It uses the appropriate visualization
There are 4 variables plotted on the graph – height, weight, density, and time. Two of the variables are encoded in the axes of the chart. The time dimension is controlled by the slider (or by hitting the play button). The density is represented by the color on the chart.
You could present this data as a table of data but it would be much harder to understand the pattern that the animation conveys in a very simple manner – not only are players getting bigger in both terms of height and weight, but the variance is increasing as well.
It makes good use of color
It uses color appropriately, by varying the saturation rather than the hue. I’ve blogged about this topic before when discussing the Wind Map. To repeat my favorite quote about this, Stephen Few states in his PDF “Practical Rules for Using Color in Charts”:
When using color to encode a sequential range of quantitative values, stick with a single hue (or a small set of closely related hues) and vary intensity from pale colors for low values to increasingly darker and brighter colors for high values
I could imagine extending this visualization in a few ways:
- Allow users to view the players that match a given height/weight combination (who exactly are the outliers?)
- Allow restricting the data to a given position (see how quarterbacks’ height/weight are distributed vs those of the offensive line)
- Compare against some other normalized metrics, such as rate of injury. Is there a correlation?
This is a great data visualization because it tells a story and it spurs the imagination towards additional areas of analysis and research.
Martin Chikilian from Toptal rounds up some common mistakes that Python programmers make.
I have made mistake #1 on multiple occasions:
Common Mistake #1: Misusing expressions as defaults for function arguments
Python allows you to specify that a function argument is optional by providing a default value for it. While this is a great feature of the language, it can lead to some confusion when the default value is mutable. For example, consider this Python function definition:
>>> def foo(bar=): # bar is optional and defaults to  if not specified ... bar.append("baz") # but this line could be problematic, as we'll see... ... return bar
A common mistake is to think that the optional argument will be set to the specified default expression each time the function is called without supplying a value for the optional argument. In the above code, for example, one might expect that calling foo() repeatedly (i.e., without specifying a bar argument) would always return ‘baz’, since the assumption would be that each time foo() is called (without a bar argument specified) bar is set to  (i.e., a new empty list).
I don’t remember for sure, but I’ve probably done something like #5, modifying a list while iterating through it.
If you write Python code, the rest of the article is worth a read