On costs and contexts

Last week on Twitter, there was a small argument on my "second-degree" network about commenting code. I'm not going to get into the specifics, but it was a response to a certain point of view. I waded in a bit to share examples from my (and others') code and later stopped engaging, but a few folks continued for a while. You know how Twitter arguments are.🤷‍♀️

Anyway, while watching people argue and counter-argue, I remembered why I dislike Twitter technical arguments and the absolutism that comes with them. I put my thoughts together in this tweet thread:

I find all these arguments on different code patterns funny. Mostly because everyone ignores two things: cost and context.

Thread.

— jukai (樹海) (@theshalvah) May 10, 2020

I'll try to expand on them some more here.

Every decision has a cost

Every technical decision has a cost. And benefits too, usually, but that's not the focus here. Generally, we know we need to do cost-benefit analysis for "big" architectural decisions like what language or cloud service to use, but we forget that even the seemingly insignificant ones have costs too.

For instance:

• I have a short block of code that needs to do some computations that might be confusing (say, bitwise arithmetic). Do I extract it into a function with a descriptive name? Cost: too many functions could make following the code hard.So, inline it and add a comment about what it does? Cost: comment could become stale, too many lines of code in the function could be harder to follow.
• Naming a variable. Do I use a variable name that's 100% descriptive? Cost: variable names could get too long and lead to a lot of horizontal scrolling. Do I use a cryptic variable name? Cost: may not be as descriptive.
• Do I use TypeScript for this project? Cost: generics and complex types could add a lot of overhead in reading the code. Okay, so should I stick with JS? Cost: less type safety, worse autocomplete.

The key is recognizing that everything has a potential cost. How you organize your code, the programming style you use, which IDE you use—everything. Even widespread "best practices" like "avoid using global variables" have costs. A lot of the time, people try to insist on the superiority of one philosophy over another without acknowledging that theirs also has its costs. I personally am skeptical of taking advice from people who act that way.

On the fly, while coding, we subconsciously evaluate these costs (probably hundreds of decisions each day) and pick which one we can bear based on our context.

Every choice has a context

The context is also massively overlooked when we get into these arguments, because we want people to agree with us. Context includes a lot of things, like:

• the developer's experience
• the project being worked on
• the target audience for the project
• the number of people working on the project
• the hierarchy in the team
• how much the developers are being paid
• the developer's job security
• the developer's personal programming philosophies and preferences
• whether the developer had breakfast that day

In an ideal world, some of these things should probably not be factors, but we don't live in an ideal world.

Context is what makes people favour one cost over another. For instance, in picking whether to switch to TypeScript or not:

• If I've been badly bitten by type-related errors in the past, I'd probably think the cost of switching to TS is worth it.
• If I haven't had any issues with OOP, I may think that the readability/learning curve cost of functional programming is not worth it.
• If I have a hard deadline, I might decide to skip refactoring this old code or writing tests.
• If I have an eye condition, I might favour adding a multiline comment over long function names. (👈 True story! I remember reading a thread about some blind developers who preferred tabs to spaces because they had to use screen readers.)

I could give a lot more examples, but you get the idea.😄

Think about the costs and their context

I started out thinking about coding arguments, but I realised that a lot of these principles often apply in life as well.

I quit university in 2017, in my fourth year (out of five). I left because I knew I couldn't take it anymore. I felt like a part of me was dying everyday. Before I took the decision (and afterwards), I talked to a few people about the possibility. Everyone was against it. Common arguments were: "you only have a year left", "don't be a quitter", "it's difficult to make it in Nigeria without a degree". Most of them meant well.

But I knew they weren't right. I literally couldn't take being in school anymore. I needed to get out. To my mind, there was no other way. And when I took my decision, I decided that that was it. I was never coming back to that place. I tore up my school documents. Drastic, yes. Necessary? To me, also yes.

Three years later, and I'm doing alright😅. I have a good job. My financial situation is exponentially better. Same for my mental health. My life doesn't feel like it's falling apart anymore. It took a lot of hard work in all these areas, but I'm wayyy better. I don't know what the future holds, but I'm pretty certain I'd have been an unimaginable wreck if I had listened to all those people. I know there's a potential cost to quitting, maybe even something I might run into much later, but to me, it was 100% worth it.

One of the biggest impacts that experience had on me was to make me more cautious in telling people what to do. Since I left, lots of people have asked me for advice on quitting school and other things, and I've learnt to be less "absolute". For instance, when someone asks me "Do I quit school?", I:

1. Let them know that it's their decision, and it depends on their situation.
2. Make them understand that it has a cost.
3. Try to describe my situation, and how I arrived at my choice.
4. Ask for information about their situation before making any suggestions.

It's a similar thing in technical arguments. Before you try to persuade someone to adopt your philosophy as The Better Way™, understand that they are operating from their context (experience, timeline, job constraints, philosophies etc), and you are operating from yours. Acknowledge that your way, better or not, has its own costs. And ultimately, don't try to force it down their throats. Leave the decision to them, and hope for the best.