Last night I was working on my final project at the coffee shop near campus. Then a group of my batchmates came, sat down, ordered coffee, and for three full hours just complained about the exact same topic: how their thesis advisor is evil, not understanding, and always asking for revisions on chapter one.

I, who was trying to focus on writing code for a patient registration backend system, could not help but have my ears burn listening to them go in circles around the exact same problem statement without ever submitting a pull request for a solution.

While sipping my black coffee which tasted increasingly bitter, I playfully thought about it. Try imagining your friend group as a large computer program. If your program is filled with classes or objects whose function is only one thing (for example a Complainer class), your system will be extremely slow. This violates the most fundamental software design principle: the SOLID Principles.

Let us dissect it one by one.

First, the Single Responsibility Principle or SRP. This principle says that every class (or friend) in your system must have one clear responsibility. If you have a friend whose only job is to complain every time you gather, they are actually fulfilling SRP. But the problem is, the value they bring is negative. A healthy friend group needs friends with balanced responsibilities: can make jokes, can listen to rants, can be invited to do group work. If they are just a Complainer class, your system will be weighed down handling their error logs every day. You need to refactor your friendship.

Second, the Open-Closed Principle or OCP. This principle says that your system should be open for extension, but closed for modification. What does this mean in the real world? Your friend group must be open to accepting new friends (extension), but do not let the identity or core values of your friendship (core module) be easily altered by outsiders. If a new person enters and suddenly dictates the hangout spot, dictates the gathering time, and dictates the conversation topics, that is a sign your OCP is breached. The defense of your social architecture is very weak.

Third, the Liskov Substitution Principle or LSP. Basically, if there are two objects from the same derivative, they must be able to replace each other without breaking the system. In a friend group, this is equivalent to the person who says yeah yeah I will come later, but on the actual day they disappear. They give a promise (interface) that they are a "HangoutFriend", but their actual behavior is a "FlakeFriend". Your system immediately crashes because you are short on people to play UNO.

Fourth, the Interface Segregation Principle or ISP. Do not force one friend to be everything to you. If you want to talk about startups and coding, find friends who are actually nerds in that field. If you want to vent about love problems, find friends with high empathy. Do not force your programmer friend to listen to your romance drama, because that is not the interface they provide. They will error out or give a weird output like telling you to break up with your partner using the command line.

Fifth, the Dependency Inversion Principle or DIP. In software, high-level modules should not depend on low-level modules. In a friend group, your happiness (high-level) should not depend 100 percent on the validation of your friends (low-level). If you feel cool only when invited to hang out by the popular circle, it means your life is too tightly coupled to them. The moment they do not invite you to play, your life immediately throws an exception.

So, stop romanticizing toxic friendships under the excuse of solidarity. Solidarity without SOLID principles will only produce spaghetti code in your mental health.

Build a friendship system that is clean, scalable, and easy to maintain. If there is a module that makes the system slow and its only job is to throw errors, then do not hesitate to deprecate it.

Khay