I’ve expressed my admiration for Paul Graham a number of times already in this young blog. He’s a successful entrepreneur, investor, innovator, writer, philosopher, language designer, and hacker. Most people would be happy to be as good at one thing as he is at any of those things. Today, let me add to his mystique.
I’m a regular on Paul Graham’s Hacker News site, but I had a hard time following the conversations and getting the full value of the site until I would hystry.com by Kartik Agaram. Kartik scraped all of the comments from Hacker News and displayed them with some extra formatting and features. There were some neat things like the ability to filter out conversations you were unintereested in and see all the parents any comment. But the thing I liked most was the way each comment had the article it related to next to it so it was easy to visually filter conversations.
Well, one day it just stopped loading new comments. I figured it was temporary and waited a day or two for it to come back, but when it didn’t, I emailed Kartik to see what was going on. He said his crawler’s email address was banned because it was putting too much of a load on the Hacker News server. That was certainly reasonable of pg to do, but I wanted to make sure he knew that I found hystry’s features to be valuable. I thought the best way to let Paul know would be to post a request on Hacker News, with a slightly inflammatory title (Reinstate hystry’s Hacker News) and a much more polite request in the text field.
What happened after that is pretty amazing. It’s worth reading through the entire thread, noting the time stamps for when things happened. To make a long story short, Paul made three changes to his running site in real time response to a dialog he was having on that discussion thread. Total time for feature request, notification, communication, two design iterations and a bug fix: 7 hours. Here’s a timeline of what happened: (note: I can’t say exactly how long this took because posts over an hour old don’t show minutes)
- Start – I make the request to let hystry crawl again because I like the way they displayed the content
- After 3 hours – After some other people commented on the issue, Paul explains that it was hard on his server and asks if I’d like anything changed on Hacker News itself
- After 4 hours – I make my recommendation and Paul makes a change to the live site within the hour
- After 5 hours – Someone recommends an alternative design and Paul implements that suggestion, again withing the hour
- After 6 hours – I notice a bug and point it out
- After 7 hours – Paul fixes the bug
Here’s what the new site looks like with the root link shown:
How did Paul make these changes so fast? Hacker News is written in Arc, his new language built on top of MzScheme. I don’t know whether the web server is his own or if it comes with MzScheme, but he has REPL access to the running server. So he made changes to the site’s code while it was running and changes were instant. Hacker News doesn’t have customers per se, but choice of technology and architecture let him provide an unforgettable user experience. This should certainly raise an eyebrow for anyone who has had deployment or downtime issues while making changes to their site.
If one of your users had a reasonable feature request, how long would it take you to publish it?
Comments at programming.reddit.com
First spewing-Coke-out-my-nose funny comment of the day: “Nice. Here I thought this was an article about Graham rewriting some history. I was pleasantly surprised.” -now look back at the title of the article. Thanks boredzo!
UPDATE: Several people have pointed out that this isn’t some technological miracle and you could do the same thing with X (for many values of X). I know. That’s why I spent about 5% of the article on it. I was impressed with his response to unsolicited feedback that was sent to him indirectly, and that he didn’t just slap out the change, he made two design iterations and a bug fix while communicating almost live with users. Much more of a social and business feat than technological.