Wouldn’t the world be a better place if we all become our own friends?
Familiar Features, Familiar Problems
Developing a social platform includes re-writing features we all know and love. This time around we were working on the Timeline and Wall features for reading threads1 by you and your friends.
The process requires querying for all the threads2 that belong on the person’s timeline (or wall). For that, we needed to get the keys of all the person’s friends, and then add that person’s own id to the list, in order to compile the list of relevant threads. After compiling these keys again and again3, a junior developer in the company asked me “why not just make people their own friends, wouldn’t that solve the issue?”
This is an interesting question, and the type of questions we encourage people to discuss in our team. This isn’t the only situation where we encounter the union of friends and self. One could argue that there are somewhat similar features on Whatsapp and Facebook Messenger. Isn’t sending yourself a message on a chat platform the same as being your own contact? I’m not sure I’m steelmanning4 this engineer’s argument, but you can absolutely say that there are technical considerations why it’d be good for a person to be their own friend. There is a functional reason behind this idea.
So? What’s the problem? Why not?
These questions are true learning opportunities for juniors5, so we took it to the white board and started considering the implications. There may end up being more arguments against this idea, in system terms. For example, how do you deal with a person trying to unfriend themselves? Do you create an exception in the database, or to the “unfriend” button? What about all the functionalities that we implemented for encouraging you to engage with your friends, how do they interact with this notion? Would adding people as their own friends force us to remove them from the list just as often as we had to add them? You end up needing to create different exceptions for the friend who’s you.
The biggest argument, in our opinion, though, is the argument of ontology. For those who wonder, “in information science, an Ontology encompasses a representation, formal naming, and definitions of the categories, properties, and relations between the concepts, data, or entities that pertain to one, many, or all domains of discourse”6
On Ontology
Every time you create a product, you end up creating an ontology, whether you meant to or not. It’s a set of understandings about the names, meanings and relationships between objects in your system. You rarely avoid altering the meanings of words to fit your ideas, slightly or beyond recognition. But, whenever you can, you should use the known, instinctive, meaning of the words you’re using.
We often tell people that they should be their own friends, or that a person’s most important relationship is with themselves (and other wise or clichéd expressions). We don’t mean these literally. We mean that one should like themselves and show themselves compassion. So when we decide that “users are their own friends”, we have a problem of ontology. We chance meeting some smart-aleck engineer down the road, who will say: “That makes no sense. No one is their own friend”. That engineer then deletes the code making people their own friends. Sometimes, they will go the extra mile and perform a disastrous database migration7.
So how do we avoid these issues? The most obvious solution is to not use words in a new, unexpected way8. But when you tread new waters, you may not have the right term. You may need to invent a new term, or extend the meaning of a different term somehow, in a way that doesn’t make immediate sense. We would grow accustomed to these terms in the end, though. No one scratched their heads when I talked about a timeline or a wall, even though these names were invented by someone lost to history working on one of the original social networks9.
Many of the best engineers I’ve worked with had an obsession with clarity. Naming something correctly now, will save you years of arguments and bugs. I think this may sound like a theoretical discussion, but I want to stress that this is a problem that happens every day, in many different contexts (not only engineering).
I went around the office and some of the other engineers contributed their own examples:
- On day one, when the Anuchat project started, the CTO called everything a “message”. It became clear that this naming convention was wrong when the CPO and the CTO had a long meeting talking about messages. You can guess what happened.
- I used to work for a company that aggregated usage data for billing purposes. We used the term meters10. We had many of our customers talking about metrics. We thought they’re the same (they are similar), but some customers were disappointed we couldn’t give them all the information and basic analysis datadog would give them.
- Has your husband ever asked you to hand him “the thing”? You know, the thing, he points in some random direction. “It’s right next to you… you know… that… thing”. You pick up the pen, the remote, and each time he says “not that” or “to the right” or “left”. He is then angry you didn’t understand he meant the screwdriver even though “he was pointing right at it.”
So, we, the junior engineer and I ended up clarifying that being your own friend wasn’t what we were looking for. He showed me the code, and we quickly came to the conclusion that there was a simpler solution. He needed a helper function.
Sometimes all we need is a little help from our friends.
-
What we call posts and comments. ↩
-
What we call posts and comments. ↩
-
Spoiler: We created a helper function instead. ↩
-
Steelman - The opposite of strawman ↩
-
And, while we love AIs here, it’s something an AI assistant could easily skip, reinforcing the developer’s way of thinking. ↩
-
Sometimes that smart aleck engineer is the head of engineering who made the original decision 6 months ago and totally forgot his own reasoning. ↩
-
Probably not facebook, even though they popularized it. ↩
-
Like your electric meter, or the parking meter on the sidewalk next to your workplace. ↩