Greg Weber

doxIQ data insight: Haskell programmers read code

Summary: By putting my slides on doxIQ, I learned that Haskell programmers read code.

At doxIQ, our entire backend uses Haskell. We believe in contributing back to the community through open source, but we also want to contribute knowledge back.

With the increasing usage of Haskell in industry, there is a hunger for practical knowledge gained from programming Haskell every day in a work environment. With that in mind, I put together some slides based on my experiences using Haskell at doxIQ and presented them at the Haskell Hackathon earlier this year. I think the talk went well. A few audience members thanked me for the talk afterwards, and some asked questions or challenged my point of view during the talk.

View the slides: Getting It Done with Haskell

A Hackathon can only host a fraction of the Haskell community, and the presentations were not recorded. I used doxIQ to host the PDF version of my slides, which has the advantage of showing me detailed data about how my document was read.

Above are some aggregate statistics. Below is the beginning of the view depth graph.

The first thing the view depth graph shows is a steep drop-off where 75% of readers that clicked on the link either closed their browser tab or clicked the download link and read off-line.

Below we have the view time per page graph.

What interested me the most about this graph is the 3-fold view time variance from 6 seconds to 18 seconds. The time on the first page is artificially high due to user and browser behavior, so we will ignore it for this analysis. We have made some improvements in doxIQ for how we record the first page view since the slides were originally posted.

For average view times greater than 15 seconds, I looked at the contents of the slides. All except one are characterized by external links or code. Seeing this pattern, I then went back through the pages to label them as code or external link in the above graph. Clicking on an external link may cause a reader to pause to click the link and possibly to switch to the tab that opens up. More interesting is how all the pages with code samples had high view times. Page 12 is the only page with greater than 15 seconds view time without code or an external link. It just has text, but that text communicates an important but nuanced idea. However, some of the view time may actually be view time on the most viewed slide, #13 because users can see parts of both pages at the same time.

The insight I gained into my audience from these analytics is that Haskell programmers do more than just skim bullet points: they read the code.

Applying this to my content means that I need to spend more effort on how I present code. Slides are not a great way to communicate code. My presentation was not code heavy in general, so overall a slide show was a good format. But there is at least one slide with a fair amount of code, and I did a poor job of formatting and presenting code in the slides, which is something my audience cared about the most. In the future if I stick with a WYSIWYG presentation program I will probably try linking to external github gists. Or I will try a different program altogether for creating slides that is better suited to displaying code.