## 07 June 2015

### Give.

When I walk down the streets of San Francisco, people sometimes ask me for money. And if I have the time, as I almost always do, I stop and talk with them about what brought them to where they are. And if I have the cash, as I almost always do, I give it to them.

People tell me that I’m foolish for giving money to people for no reason. My donations aren’t tax-deductible! They don’t go on the record anywhere! These people might just be using my hard-earned money to buy alcohol and drugs!

So what? I use my money to buy alcohol and drugs. Because like an awful lot of people in the modern west, I’m lonely. My vices are a distraction to tide me over until I meet another lonely someone whose flaws are compatible enough with my own that we can rub our woes together and feel whole again.

So if you can give, give. What the fuck does someone with a steady job need with another few bucks? Let it go. It might make the difference between life and death for someone who was dealt a shitty hand.

## 27 May 2015

### Don’t say what you mean.

In conversation, I used to think it was good to say what you meant. I thought doing so would help me be understood. But I learned very quickly when tutoring computer science students in college that this strategy does not work in general.

The real challenge is to say what you think will make you understood. This turns out to be hard, because you need to develop a mental model of another person’s understanding. It means looking at what you’re trying to say in a new way. This has happy side effects, though: it makes you more empathetic toward others, and gives you a better understanding of the subject.

The old joke “Those who can’t do, teach” is a stupid statement—but an awesome prescription! If you can’t do it, teach it! By explaining things you’ve learned to others, you can develop your understanding and skill. When you can explain something to anyone, it means you have a fully developed model of it in your mind, one that you can look at from anyone’s point of view.

Similarly, when we’re trying to understand others, we should not be listening to what they say but trying to understand what they mean. When someone says something offensive or upsetting, often they didn’t intend for it to sound that way, and the intent matters. Being misunderstood feels bad; think about how often you’ve probably made someone feel that way because you didn’t take a moment to think.

As listeners, we should ask for clarification and try to understand why something was said. Sometimes it’s because a person has a belief we disagree with, or a bias we think is unfair. Sometimes it’s because we were hurtful to them, and they were acting in self-defense. In these cases we can use the moment as an opportunity to learn and teach, rather than getting offended and putting everyone involved on the defensive.

The vast majority of the time, people are basically well-intentioned and just trip a little on the delivery. Giving them the benefit of the doubt is important to develop mutual understanding.

## 23 May 2015

### Consent is important. Don’t oversimplify it.

Rape happens. It’s an awful reality, which a lot of good people are working very hard to fix. That starts with teaching people about consent and why it’s essential to healthy sexual interactions. But a lot of explanations of consent, while undeniably good and well intentioned, fall short of the truth.

The conventional wisdom is essentially you should only have sex if everyone involved wants to. That’s true, but not the whole story. The thing is, there are many reasons that people might want to have sex, and they might disagree with your reasons, or even your idea of what it means to want something. And that’s okay.

I’ve been in healthy relationships in which there was a mutual agreement that initiating sex while the other partner was asleep was perfectly acceptable. It was understood that if either of us wanted an interaction to stop, we would say so and the other partner would respect that. So my partner initiated sex with me while I was asleep, and vice versa—does that make us both rapists? Of course not. Those who would say yes aren’t examining deeply enough what consent really is.

I’ve been in situations where one partner was in the mood for sex, while the other partner was not. Yet the non-aroused partner still helped the aroused one to feel satisfied. They did something they didn’t “want” to do, and yet no rape occurred—it was simply a case of a person doing something to please their partner with the understanding of non-obligation and reciprocity. That’s not only okay, it’s a prominent feature of good sex and good relationships.

I have experienced unwanted sexual situations. They were horrible, and I wouldn’t wish them on anyone. But consent is not a black-and-white, unequivocal issue. It relies on a continual dialogue of reciprocity and mutuality, and it’s up to individuals to decide what is and is not okay.

It’s not for an outsider to decide from their armchair whether some interaction between other people was okay or not. If someone says they were raped, you listen to them. And if they say they weren’t, you listen to them then, too.

## 29 December 2014

### Why I Don’t Use Syntax Highlighting

When I’m programming, and a fellow programmer looks over my shoulder, the first thing they invariably say is some variation of “Wow, no syntax highlighting? I can hardly read that.”

Ever since I started programming almost 15 years ago, I have preferred very minimal syntax highlighting—typically just keywords, comments, and string literals. I have synaesthesia, so I find anything more involved to be distracting, due to the mismatch between my perception of the colour of a word and the colour in which it’s rendered on the screen. So now my default programming theme is simply black text on a white background, usually in Source Code Pro.

When I see someone working in a wild palette of pinks and purples and yellows and greens, I can agree that it looks pretty—but it interferes with my ability to read the code. It feels nothing but gratuitous. When you read a novel, the words aren’t highlighted for their grammatical categories; when you read mathematics, the symbols aren’t highlighted for their syntactic categories; so why do we do this in programming?

Perhaps it’s because our notations are impoverished by their rendition in monospaced fonts using the subset of ASCII that’s convenient to type on an American keyboard—but couldn’t we use proportional fonts and better input methods? Perhaps it’s because our languages include lexical elements such as comments and (sometimes) string literals that can span multiple lines and “run away” to produce odd syntactic errors—but couldn’t we make such error messages smarter? Perhaps it’s because we don’t know our own languages well enough, so we need interactive help on which keywords are available and which syntax is valid—but why do our languages have so much syntax?

Often, syntax highlighting is outright incorrect, particularly in syntactically complex languages like C++ and Perl. Just as often, it’s misleading to beginners, who tend to interpret things highlighted in a way they don’t understand as erroneous, even if they’re actually correct.

Every justification I can find for syntax highlighting can be refuted by an appeal to better tooling. It appears that we only use syntax highlighting as a workaround for the lack of these tools, and because it’s something to which we grow accustomed by virtue of its ubiquity.

## 28 December 2014

### A Simple Argument for Immutable Objects

You have an integer value 4 stored in the variable x.

int x = 4;

You change x.

++x;

In doing so, you have not changed 4 into 5, you have merely changed x to refer to the value 5.

Now suppose you have a class.

class Person {
…
};

Instances of this class are values representing states of an object in your problem domain.

class Person {
private:
string name;
int year_of_birth;
…
};

You want to ensure that these values always represent valid object states. You can do this by prohibiting invalid state transitions.

class Person {
private:
string name;
int year_of_birth;
public:
void set_name(const string& name) {
if (name.empty())
throw invalid_argument("name must be non-empty");
this->name = name;
}
void set_age(const int year_of_birth) {
if (year_of_birth <= 0)
throw invalid_argument("age must be positive");
this->year_of_birth = year_of_birth;
}
…
};

You can also do this by prohibiting the construction of invalid states, and prohibiting all state transitions.

class Person {
public:
const string name;
const int year_of_birth;
Person(const string& name, const int year_of_birth)
: name(name), year_of_birth(year_of_birth) {
if (name.empty())
throw invalid_argument("name must be non-empty");
if (year_of_birth <= 0)
throw invalid_argument("age must be positive");
}
};

Now the values are correct by construction and immutable. All of your validation logic is centralised, so you can verify it in one place. When you want to represent a new state, you simply construct a new value to represent it.

auto me = make_shared<Person>("Jonathan", 1991);
me = make_shared<Person>("Jon", me->year_of_birth);

Creating a new Person to represent the person I am after adopting a nickname does not change the Person I was before adopting a nickname. I am only changing what me refers to.

Whereas a mutable object pretends to be a state, an immutable object represents a state. The latter is not only simpler to reason about, but also more honest about what software is actually doing: representing.