A couple years ago, I did my own analysis of all Hacker News submissions (http://minimaxir.com/2014/02/hacking-hacker-news/) and also wrote a script around that time to get all data (https://github.com/minimaxir/get-all-hacker-news-submissions... , see also a modern dataset on Kaggle derived from it: https://www.kaggle.com/hacker-news/hacker-news-posts). I only looked at the # of points as a metric for quality, so front v. back with this approach is interesting. Given the good work in this post, I may take another look at the data myself.

This is a case where the sample size used may be problematic. "425 fronts against 570 corresponding backs" (n = 995), in the grand scheme of Hacker News, is not a lot, even if statistical analysis permits it (example: the by-hour Chi-Sq test, which barely hits the 5-per-cell assumption). Given the method of collection by scraping the front page directly, this is understandable, though.

However, that presents a problem. the front-page algorithm has changed in recent months and I myself have had difficulty predicting what makes the front page and what doesn't (and what ends up making the front page hours after being submitted for no reason). With relatively new features like the second-chance pool and explicit dupe marking, there is new quality control of the front page thanks to dang/sctb. That is another issue of looking at a small subset of HN data; it does not reflect the site as a whole, although looking at more-recent data might be more beneficial for optimizing one's own posts.