All or nothing is not an option (or why I love Beeminder)

This post is about a better way of creating good habits in your life. I’m going to start with my desire to have the habit of working out. The lessons here can be applied to everything and I’m going to show you some more examples at the end.

I could track my physical exercise to make sure I keep up. I could use an app like Google Fit. The first day I meet my goal, but eventually, my days will look something like this:

Google FitI already have two missed goals. It’s very easy to get discouraged by missing a goal one day, or a few days in a row, and then drop out of the plan to improve fitness. This is a very bad way of creating new habits.

The problem with this, as with recurring to-do items is that the granularity is too low: a day. Google fit is telling me I failed two days out of four and not counting than on those two other days I made up for it. If Google fit was measuring activity in four days intervals that would have been a success, instead of a half success.

But four days might be too short too. A long weekend and boom! You are out! Maybe we should go for a week or even a month. A month is a nice chunk of time, but it has another problem: it’s so big, you might not know you are actually failing until you are too close to the end to fix it. And even if you fix it, working out like mad on the lat 4 days of every month is not healthy or habit forming.

What we need is something that won’t punish us for a day of rest, but will still keep pushing us up every day. That is Beeminder. Look at my working out chart:

Beeminder chart for working out

Beeminder legend

The pink line with green dots are my data points, the information about when and how much I worked out. It is measured in Fitocracy points, but it could be time working out, kilometers run, kilocalories burnt or anything else you want.

The yellow brick road is my goal. I want to always be above it. The yellow brick road keeps going up every day, so I need to keep on working out to reach my goal. Crossing it is called derailment and you can see it actually happened around mid October. When you cross it, the system resets, gives you a week of advantage and then re-starts. What happened around mid October is that I had a trip, but that’s not excuse. You see… if you allow things like a trip to be an excuse, it’s easy to lose a good habit.

How do you deal with eventualities then? You build up a buffer. Towards the end of November, for example, I did that. Unfortunately then I got a cold and that ate most of my buffer right away, but I’m going up again, building a buffer and staying on the good side of the yellow brick road.

The beauty of this system is that it doesn’t judge a single day, it judges your progress, but it keeps reminding you that you should be making progress.

Another advantage of Beeminder is keeping up with good habits without a routine. If you ask most gym-goes when they go to gym, they have a routine: Monday and Wednesdays! or something like that. I have preferred days, but I don’t have a strict routine, my life just doesn’t allow it, it’s too chaotic. When you don’t have a strict routine it’s very easy to forget to go to the gym because our brains are very bad at correctly keeping track of how much we worked out this week.

You may have noticed the big two numbers on the background of the chart. 10d means 10 days, and that’s how big the buffer is. I could sit on my ass for 10 days and not derail. But then I would be in a very precarious situation in which any eventuality will cause me to derail. I don’t want that to happen, so, I’ll attempt to keep my buffer at 10 days or more. Which leads me to the second number.

$5 is how much derailing will cost me. Those are real dollars, the ones you have to work for. Talk about an incentive! That’s Beeminder’s business model, that’s how they sustain themselves. And it’s a beautiful system because it only hurts when you do something bad, and that penalty is what makes the system work, so you are paying Beeminder only for doing its job. If you never fail, it’s free.

And each time it fails, the amount will go up, so, further failures will be more expensive. I been tinkering with my workouts recently, trying to find the right amount to do every week, so I keep reseting the amount to $5, but once things are stable, I’ll let it go up.

Another thing that I’m doing for my fitness and health is meal tracking. Meal tracking also has this insidious property of an all or nothing system. I started tracking them and one day I forgot. The next day I didn’t forget, but since the data was corrupt already, more corruption wouldn’t be that bad (broken window syndrome?) and the day after that I completely forgot I was doing meal tracking.

I’m still not sure if incomplete meal tracking data is useful or not, but I know the all-or-nothing situation is not conducive to forming habits. Enter Beeminder! First I tried entering how many meals a week I was tracking, but that allowed every day to be corrupt. It’s easy to track meals, it’s harder to track snacks. Allowing every day to be corrupt means you can just track meals, ignore snacks and be successful in the eyes of Beeminder.

Right now I’m experimenting with forcing myself to track 2 days a week, and I’m doing well:


Beeminder for meal tracking

That’s where the angle of the yellow brick line comes from. In that chart is 2 per week. If I continue to do well, I’ll keep increasing it, possibly up to 5 or 6.

These are just a couple of examples of what I’m tracking right now. Beeminder comes ready packages with many settings for different tasks and they keep adding them. Take a look at the screen for creating a new goal to have an idea:

Beeminder create goal

Beeminder is not that easy to use. It’s a power-tool, but I really recommend it. Whenever you want to have a new habit in your life, that’s the way to go.

How Star Trek into Darkness should have ended

Stop reading if you haven’t seen the movie yet, as obviously this will be a big spoiler.

I think Star Trek into Darkness should have ended with Kirk dead. I don’t care if they revive them in the next one, that’s fine. A friend told me:

I didn’t even realize that Kirk was dying, they wouldn’t kill him, it was just a small setback.

I think story tellers should be bolder and surprise us more.

I think they should have shown McCoy doing something with the body that can be later, in another movie, revealed as putting it in stasis. I think Spock shouldn’t have chased Kahn and have a fist fight. He should have been busy making sure the good of the many outweigh the revenge of the one by saving the Enterprise and making sure his crew was out of danger.

Hold on Pablo… you mean you want to end a movie with one of the main characters dead?

Yes, that would have been brave, although not new. Someone did it before and it might be familiar:

What about Kahn?

He should have run away. That’s it. Hold on… even better… he should have fled with his crippled ship.

But then… the bad guy won?

Yes. It would have been brave and it would have built a lot of tension and expectations for the next movie. Although, it wouldn’t have been the first franchise to have the bad guys win in one of their movies:

Wrapped exceptions in Ruby

Sometimes you want to raise an exception when a method fails but without losing information about an inner exception. Let me explain it with an example.

At Watu we have a method that causes a user to be indexed in our search engine. This method is called many times in different situations. One of those situations is when indexing most or all of our users. Recently, something failed and I got this exception:

undefined method `each' for #<String:0x10dab8fc>

Something that should be an array is actually a string. In this case the indexing method is correct, it’s just getting broken data. I want to fix the bug in the data generation, but to locate it, I need to know which user has broken data. I added a rescue clause to my indexing method to show me that data:

def index
  # ...
  raise "Error when indexing user #{self}"

Now I get something like:

Error when indexing user #<User:1234>

which allows me know that user 1234 has something wrong in its data. The problem is that now I have no idea what the issue is. I lost the information about trying to call each on a string.

The solution to this problem is exception wrapping (or nesting). You want the custom exception to wrap the other one so that you have both pieces of information. This, for example, exists in Java and if you search the web you’ll find ways on how to implement it in Ruby. Implementing this manually is not needed anymore since Ruby 2.1. Unfortunately, it’s a bit hidden and the tools haven’t caught up yet.

The secret lies in a new method in the class Exception called, cause. At the time of this writing it doesn’t even have documentation:

No documentation for the method Exception#cause

No documentation for the method Exception#cause

Using it is very straightforward. Just raise an exception in the rescue clause and the new exception will have the previous one as its cause. For example, in this case:

  a = 1 / 0
  raise "Something went wrong"

you get two exceptions: the divided-by-zero wrapped inside one with the “Something went wrong” message.

The problem arrises that nobody seems to be using the causes of exceptions yet. If you run that in IRB, this is what you get:

RuntimeError: Something went wrong
        from (irb):4:in `rescue in irb_binding'
        from (irb):1
        from /Users/pupeno/.rvm/rubies/ruby-2.1.0/bin/irb:11:in `&lt;main&gt;'

But the exception’s cause is in there… hidden. If you catch the outer exception you can access its cause. For example:

    a = 1 / 0
    raise "Something went wrong"
rescue => e
  puts e
  puts e.cause

would produce:

Something went wrong
divided by 0

The reason why it doesn’t produce something like that by default is because whatever IRB is using to print exceptions is ignoring the exception’s cause. Now we’ll have to wait until all the tools catch up with this new feature.

Well, we don’t actually have to wait. Aside from the fact that most of them are open source and you can fix them yourself, Ruby allows you to monkey patch so you can fix your own copy of these tools.

In my case I needed rake to print inner exceptions, so I wrote this monkey patch (which works for rake 10.1.1):

module Rake
  class Application
    def display_error_message(ex)
      trace "#{name} aborted!"
      trace "Tasks: #{ex.chain}" if has_chain?(ex)
      trace "(See full trace by running task with --trace)" unless options.backtrace


    def display_exception(ex, margin="")
      trace "#{margin}#{ex.message}"
      if options.backtrace
        trace "#{margin}#{ex.backtrace.join("\n#{margin}")}"
        trace "#{margin}#{Backtrace.collapse(ex.backtrace).join("\n#{margin}")}"
      if ex.respond_to?(:cause) && !ex.cause.nil? # Ruby < 2.1.0 doesn't have *cause*
        trace "#{margin}which was caused by:"
        display_exception(ex.cause, "#{margin} ")

This is something that I would like to see in rake itself so I created an issue request (#253). Take a look at it to follow the development of this feature and hopefully, all tools will start displaying causes in one way or another.

The danger of the wide product

Working at Watu I came up with the categorization of products by width. There are products that are wide and products that are narrow. They have different traits and understanding those traits is important. Watu is a wide product. Twitter is a narrow product while Facebook is wider. This is not a matter of complexity or size but a matter of how many modules or independent parts a product has. An example of a narrow but complex product is Apple’s Siri.

GitHub used to be a narrow product: git repositories. Now it is a wider product: git repositories plus issue tracker, plus wiki for documentation, plus public pages. You can think of more features that GitHub could add to make it a wider product: product management, customer management, etc. Adding those features make GitHub a wider product, while adding pull requests handling doesn’t.

The advantage of wider products is that they are the all in one solution for more people than narrow products. That’s because people tend to have a wide variety of needs. If your social needs is just sending short messages, Twitter is the all-in-one, but if you also share pics, organize events, form groups, etc., then Twitter is no longer the all-in-one product and you need a wider solution, like Facebook.

The advantage of being the all-in-one product is that if your users are not looking outside your product they are less likely to jump to the competition. They are also more likely to put up with an inferior solution in one or several aspects because the other aspects make up for it and the seamless interconnection of the different parts of the product is in itself a big plus.

For example, if Facebook implements a Doodle-like module, it doesn’t have to be as good as Doodle to make me switch to it, because I’m already inside Facebook for socializing and event handling, so also using it for deciding when an event happens is very convenient (Facebook, please, don’t kill Doodle… just buy them if you have to).

But, there are some dangers to building wide products. Once is that it’s harder to keep focus because you need to constantly jump between modules. If I was to develop Twitter by myself I would be much more effective than if I was to develop Facebook, because I would have less context switching. I believe this point is not true when you have more people than modules so each person or team can keep focus. But when you are a small three-person startup, this is something worth considering.

Another danger of having a wide product is that, even as a developer, it’s scary to jump outside. At Watu we saw several opportunities to build different products where a customer came with a need that didn’t match Watu perfectly. Every time we discarded it because building a new product and making it as wide as Watu was too much work and modifying Watu was undesirable. The truth is that maybe those products didn’t need to be as wide, they didn’t need all these modules and features, but that fact was very hard to see when we were living and breathing Watu every day.

A return to space

In the 1990s we had what I consider the two best space related TV shows ever produced: Star Trek: The Next Generation and Babylon 5. TNG showed humans as explorers, evolved beings trying to move forward peacefully. It was a beautiful picture, something to aim for. Babylon 5 was more realistic: we still have problems and it’ll be a struggle, but we can do it. Babylon 5: In the beginning, one of the movies of the franchise, has some of the most realistic space battles. I read they got NASA’s Jet Propulsion Laboratory to do the math for them.

And then space died.

It was a slow and painful death. The spinoff of B5 lasted half a season. Star Trek managed to go on for much longer, but the quality went down until Enterprise was cancelled before a proper ending. And then we have Firefly… possibly the last big attempt at depicting humans living in space. It suffered the same fate as B5’s spinoff.

These developments are not just about fiction. Space exploration has been disappointing us for the last 30 years or so. We never went back to the moon. We never went to Mars. The International Space Station is amazing, but it’s not the space habitats we used to dream about. NASA cancelled the Space Shuttle program. The Hubble telescope was almost decommissioned. We stopped dreaming…

Well, not everybody stopped dreaming. And in a world where making a difference is becoming easier every day, some people have enough resources to do it even when it comes to something as expensive and crazy as space. People like Jeff Bezos (Blue Origin), Richard Branson (Virgin Galactic), and my favorite, Elon Musk (SpaceX):

In 2009 we saw the return of Star Trek with J. J. Abrams reboot. It’s not a good Star Trek movie but it is a good action movie, that happens in space, in the future, a future where humans have expanded throughout the galaxy and created a peaceful federation of planets. And this year we had another Star Trek movie for which I would say the previous statement applies as well. They are fun… but what really excites me is this:

potentially realistic depictions of space…

Maybe we are looking up again… hopefully… we’ll start dreaming again soon.

I need a new word

Yesterday I was going to meet a friend. I arrived very late due to poor planning on my side (leaving late) but also because I got lost. Well… I didn’t really get lost. I knew exactly where I was all the time. Pinpoint accuracy by my GPS. But I didn’t know how to proceed because buses got diverted, some may have been cancelled but I wasn’t sure.

One part of the definition of “lost” is the correct one:

Unable to find one’s way

but the other part is not:

not knowing one’s whereabouts

and when I say I got lost, I may sound like a lier: “How can you possible get lost with your phone/GPS/google maps?”. I need a new word that means “I know where I am but not how to proceed.”