Programmers are hipster librarians

Author’s note:

This is an old blog post. I originally wrote it for the blog at my startup, (, which has long since shut down. I ported some of the posts here, because they were popular, and some people asked me to resurrect them. Remember, these are old, things might have changed, blah blah blah...

In a world where the solution to nearly any problem is available online, for free, the most effective programmers know how to quickly get answers to their programming questions. How? In practice, programming often reduces to a simple loop:

while coding do
  next unless Problem.unsolved?
  frustration = 1
  question = Question.formulate(Problem)

  while frustration < MAX_FRUSTRATION
    answer = ||
    break unless answer.nil?
    frustration += 1

  Problem.solve!(answer) || raise IGiveUp("I'm moving to the wilderness and raising goats.")

Anyone can grind away on the outer loop, but we’ve all seen what happens to an O(n^2)[0] algorithm with an inefficient inner loop [1]. For programmers, the thing that separates a novice from a pro is the the ability to get answers quickly. If you have a limited personal knowledge base, the act of formulating a good question is critically difficult. As an experienced programmer, you’ve spent years building up a highly specialized mental index that gives you quick access to a lot of programming information.

In short, you’re a not an expert programmer; you’re a librarian in an ironic t-shirt.

…a hipster librarian, using artisinal, free-range hash tables

It makes me a little sad to say this, but unless you’re of a Certain Age, you may never have seen one of these in real life:

The original Google.

No, that’s not (just) a piece of kitsch in a startup designer’s apartment – it’s an index! Once upon a time, if you wanted to find something in a library, you walked up to one of these, looked up whatever terms you cared about [2], and then you found the index cards that related to your topic by flipping through the correct drawer. Those cards then pointed you to the books you cared about.

To use a card catalog, you had to be creative enough to think of all the terms that might relate to your question, look stuff up in the cards, fetch the books, read them, come up with more words, look those up, etc. until you found your answer.

Sound familiar? We’ve replaced the rooms full of furniture with rooms full of computers [3], but the process today is no less quaint.

OK, so you’re old. What’s the point?

The point is, when it comes to answering programming questions, we’re still running an inefficient algorithm: the prerequiste of getting an answer is knowing how to ask the right question. And that takes experience.

But why? What’s the one thing you usually know when you have a problem with code? You know where you are in the code. You know the package, the class, the method…you often know the specific lines that are causing you trouble. So why don’t we organize our programming knowledge that way?

"My terminal? Yeah, you've probably never emulated it."

Say that you’re new at Ruby, and you want to know how to delete elements that match a certain condition. Wouldn’t it be convenient if the documentation for Hash#delete, already had an answer for someone with the same problem? Or perhaps you’re getting an exception when loading a database in Rails. So you go to the page for PG:Error and see why you might be getting that exception. That’s not a card catalog – that’s an index built for programmers.

Programmers live in code. Coding knowledge should live there too.

Despite living through a revolution in the availability of free programming knowledge on the internet, most of us are still stabbing in the dark when we need to find answers to hard questions. Programmers need access to all sorts of knowledge: questions, answers, blog posts, books, bugs, commits, comments, and so on. And programmers live in code. So why not bring the two together? That’s our goal: we’re creating a community where anyone can attach programming knowledge to the code where it belongs.

We’ve been adding features to Omniref that make it possible for anyone to ask questions on a particular package, or even a particular line of code. And in the coming weeks we’re going to be expanding on these features in new and (we hope) exciting ways. Our goal is to build a code-based reference, by and for the programming community. We want to make a place where you can find anything: blogs, books, questions, bugs, etc. simply by looking for the code you care about.


0) Yes, OK…this is technically O(n*m). Let’s assume that in the limit of zero knowledge, you’re a terrible question asker, but incredibly persistent. This seems consistent with the most annoying people we know.

1) There are a lot of goat videos out there. Coincidence? I think not.

2) For example, FORTRAN (or perhaps, MISERY or LANGUAGES, ANCIENT).

3) I can’t resist.
© 2017, Tim Robertson