Short-Circuit Statements

What is a short-circuit statement? In this case, I’m not talking about the language feature related to boolean comparisons, but instead I’m talking about statements which cause a method to return as soon as some conclusion has definitely been reached. Here’s an example from a very simple compareTo method in Java:

public int compareTo(Foobar that) {
  if (that == null) return -1;
  if (this._value < that._value) return -1;
  if (this._value > that._value) return +1;
  return 0;

In this example, each line (except the last one) would qualify as a short circuit statement; that is, they all return as soon as a definite answer is determined, thus leaving some code in the method un-run.  If we weren’t using short circuit statements, then the code may look like this:

public int compareTo(Foobar that) {
  int result = 0;
  if (that == null) {
    if (this._value == that._value) {
      if (this._value < that._value) {
        result = -1;
      } else {
        result = +1;
  return result;

For something this simple, there isn’t a huge difference in the complexity between the two functions, but it still demonstrates the point.  Many people ardently recommend always having a single return statement in any function, and would strongly advocate using the second example over the first.  However, I would argue that the first is superior because it better respects the unit economy of the reader.

Short circuit statements allow a reader to take certain facts for granted for the remainder of a method.  In the first example, after reading the first line of the method, the reader knows that they will never have to worry about the that variable having a null value for the rest of the method.  In the second example, the reader will have to carry the context of whether he is still reading code within the first if statement.  Every short circuit statement removes one item from the set of things one must consider while reading the remainder of the method.

Naturally, this example is pretty simplistic, and it’s a stretch to claim that either method is more complicated than the other.  However, consider if this weren’t a simple example. If this were a formula to compute an amortization table for a home mortgage, then the first few lines may look like this:

public AmortizationSchedule computeSchedule(
int principle, float rate, int term) {
  if (principle <= 0) throw new IllegalArgumentException(
      "Principle must be greater than zero");
  if (rate < 0.0) throw new IllegalArgumentException(
      "Rate cannot be less than zero");
  if (term <= 0) throw new IllegalArgumentException(
      "Term must be greater than zero");
  // Here is the 20 or so lines to compute the schedule...

In this case, there may be a substantial amount of code following this brief preamble, and none of it has to consider what may happen if these invariants are broken. This greatly simplifies the act of writing the code, the logic of the code itself, and the process of maintaining the code later on.

What flipped my understanding of “white privilege”

My White Friend Asked Me on Facebook to Explain White Privilege. I Decided to Be Honest
by Lori Lakin Hutcherson


I read this all the way to the end, and found it extremely well-written and enlightening. Even if you don’t want to read the whole thing, you can get a lot of value from just the opening and closing few paragraphs.

I’ve always been troubled by the phrase “white privilege” for exactly the reasons stated in the opening of the piece by the author’s friend.  And her answer to him resonates with me.  To paraphrase her excellent formulation: white privilege isn’t a positive benefit that white people receive overtly, some kind of undeserved handout, or something white people need to feel guilty about.  Instead, it’s a lack of the kind of hostility, skepticism, and type-casting directed exclusively at people who are different by not being white.

Another illuminating point comes out as she enumerates a small sample of racist experiences she’s personally encountered.  She’s not saying that all white people are racist… nor even that very many of them are.  But it’s common enough that the rare instances of it are relentless, and that makes every interaction with white people tinged with a subtle fear of yet another nasty encounter.

It’s fantastic how far we have come at eliminating the most horrific forms of institutional and official racism (largely due to the heroic efforts of black men and women of generations past).  But, accounts like Ms. Hutcherson’s make it clear that it’s not completely gone by a long shot.  I think this is an essential read to understanding the character of the racism that yet remains in our society.

Finally, her advice to people who want to fight this remaining racism also resonates with me.  It’s not enough to merely not be racist to help with the fight.  Good on you if you aren’t, but it’s not enough to move things forward.  It requires that special effort to keep an eye out for the little digs, skeptical remarks, and subtle insults and to challenge them.  Sometimes they’re not meant as hostile remarks, and the offender only needs a polite reminder.  Sometimes it’s not so benign.  But, especially if you happen to be white and see another white person doing these things, be the one to have the courage to call bullshit.  That’s what helps and can make a difference.

Breaking Out of Consensus Deadlock

Back when I was working in a very small start-up with only two other people, we would often have a great deal of difficulty coming to decisions.  We would have seemingly endless meetings where each person would express their viewpoint, then someone would rebut that viewpoint, then the first person would express it again in slightly different words.  On and on, and sometimes about things which wound up being pretty trivial.  However, since there were only three of us, it felt like we ought be able to come up with some kind of consensus, but seldom was it that easy.

We had fallen into the trap of consensus deadlock.

I think of consensus deadlock as being any time a group of people gets stuck on making a decision because:

  1. there’s not enough data to make a clear decision obvious
  2. everyone feels that a unanimous decision is necessary
  3. no one is willing to ceed the decision to someone else
  4. there’s no clear owner for the decision

Naturally, there are a bunch of techniques to break out of the deadlock, and they all involve removing one of the things in the list.  The best thing to do, when it’s possible, is to figure out what information would tip the scales, and then go get that data (#1).  Of course, that’s not always feasible.  In that case, you might stop to consider how strongly you each feel about the issue, and choose to go with the approach someone feels most strongly about (#2).  You might also try thinking over the reversibility of the decision, and allowing someone else to give their idea a shot (#3).

Those are all good ways to break the deadlock, but perhaps the best way is to assign the decision to someone, and then hold them accountable for making a sound decision.  Of course, that doesn’t mean letting them simply go do whatever they want.  In order for this to end well, owning a decision involves a lot of responsibilities.

The decision owner’s job is really to pull everything together, and then follow the data where it leads.  First, the owner needs to ensure that all the available data has been gathered and is available for consideration by the team.  Depending upon the decision, this may be more easily said than done.  Second, the owner needs to collect feedback from everyone affected by the decision and give full consideration to each point of view.  In particular, this means that they should be able to represent each point of view as well as they represent their own.  Finally, the owner must be able to weigh the pros and cons of all those positions, measure them against the available data, and then present a clearly reasoned rationale for choosing a particular course along with its strengths and weaknesses.

The job of each other team member is to help the decision owner reach a good decision.  This may be offering up what data they have (all of it… not just what leads to a certain conclusion they support).  This might be to pose questions which are critical to understanding the problem.  This might be to help brainstorm various possible options and their pros and cons.  At all times, though, each team member needs to remain supportive of the process and the decision owner’s authority over that particular decision.


The only way this technique works is for every member of the team to act in a mature and responsible manner.  The decision owner has to be able to step back from a pet idea to consider all possibilities, and the rest of the team has to trust that the decision owner is honestly considering all points of view.  If, at any point, someone on the team feels this isn’t the case, a discussion becomes necessary about whether process is being followed faithfully—not about the particular details of the decision at hand.  That makes it much easier for everyone to start from a place of agreement, and to get back on track.