Probability is a hard topic for me in part because it's easy to make trivial arithmetic errors and because it's hard to visualize and understand the problem inside my head. It's very easy to wind up solving a subtly but fatally different problem than what the textbook asks for, and while it's easy to check arithmetic errors, it's impossible to check mistakes in my reasoning.

What's a guy to do? One thought is to write a few lines that describe the problem in your favourite programming language to check your result. This lets you model that strange probability question in terms of following simple instructions to get to the final solution, and it's a powerful and natural way of expressing these kinds of ambiguous, wishy-washy problems. Though the following method won't show you the exact answer and certainly can't help you on an exam, it's a great way of double-checking your work.

For example, what if the problem calls for: "Three red and two blue balls are in a bowl. If you take out two red ones, what's the probability that the next ball will be blue?" By using just ordinary math, you can sort of see that it's \(\frac{2}{3}\), but it's often quite hard to justify your reasoning this way.

What if we can test that concretely? Wouldn't it be wonderful if we could write something like this?

def test():
    bowl = ["Red", "Red", "Red", "Blue", "Blue"]
    bowl.remove("Red")
    bowl.remove("Red")
    return probability(draw_one(bowl) == "Blue")

I'll show you how to do exactly this. The conceptual difference between reasoning about the math abstractly versus coding the steps out explicitly feels like pinning jello to a tree vs. wielding a staple gun with precision and power.

Read more…

So now you have to eat Brussels sprouts. Whether by force or thanks to a dietary experiment gone horribly wrong, there's no turning back now. You have to shove those green balls of goop down your gullet one way or another. How could you possibly cope? Like most new Brussels-sprout survivors, you might go through the following five stages to learn to deal with this strange new culinary monstrosity:

1. Denial. "This can't be happening. I'm not eating Brussels sprouts! This isn't right. What possessed me to even try?"
2. Anger. "Why on earth am I eating Brussels sprouts? Why do I have to deal with this? There are so many better foods I could be eating! Why can't I just eat those?"
3. Bargaining. "What if I switch to Broccoli instead just for one night? Nothing bad could possibly come of that, right?
4. Depression. "There certainly can't be anything worse than Brussels sprouts. I'm doomed to eat them as long as I live."
5. Acceptance. "Well, at least it's not asparagus."

And well gosh, you're eating Brussels sprouts just like that.

I find that any new change can feel a lot like Brussels sprouts. Whether you're first starting college or learning a new programming language or framework, it's often hard to adjust. On the other hand, this opportunity cost is one part of what binds communities together because the initial stomachache separates the "in" crowd from the "out" crowd.

Before you join a community centered around a software product for example, you have to look at it and decide whether it's worth it to jump in. You then have to take that first painful spoonful and either pack your bags or decide to stick around. Once you're entrenched in that community, it's hard to leave because now that you're used to eating Brussels sprouts, switching to Cauliflower seems like a downright daunting task.

This is partly why engineers get so easily opinionated about their favorite technology. Whether you use Vim or Emacs, ruby/rails or Python/Django, PC or Mac, it's easier to justify your love for your chosen path because understanding the alternative means swallowing your pride and a few spoonfuls of Brussels sprouts.

Wow! Hey look everybody, I have an Interblag now! Everyone can go from not-looking-at-my-home-page to not-reading-my-blog. What an upgrade!

Only a few interesting posts from now, I'll be the star of Hackernews.