Sorted by New


Prediction Markets Don't Reveal The Territory

Prediction markets are really fascinating. You should also touch on the idea of assassination markets, which I'd say are a subset of prediction markets where the contract price can influence the likelihood of the outcome.

When is pair-programming superior to regular programming?

I don't think pair programming is ever *strictly* better than solo programming, but I have found it to be a great way to help teach skills that are hard to describe algorithmically:

Some specific cases:

  • Debugging: when it comes to debugging, you can read books and watch youtube videos, but you get so much from sitting next to someone who has a good debugging loop.
  • Performance & Optimization: great to watch how other people do this.
  • Architecture: this is less about implementation and more thinking through medium-level architecture things. Specifically, picking the right abstractions and patterns.

A non-obvious one:

  • Overcoming impostor syndrome: I did a Recurse Center batch a few years ago and pair programmed with someone who had >20 years experience, the majority at Google. He wrote half the standard library for a very well-known programming language. So I was pleasantly surprised when I found out that even he reads the docs and sometimes forgets how to do things in that language.
  • Figuring out what's normal: I couldn't, for the life of me, figure out how to use kubernetes as a friendly part of my development workflow. I pair programmed with someone who was a professional K8s consultant, and asked them about persistent volumes for a postgres instance. I expected a "oh yeah, use this YAML setting" but actually got ¯\_(ツ)_/¯. So it felt good to know that I wasn't the only one who struggles with technology.