My personal mission is to leave the world a better place then it was when I showed up. In order to get there, I fix a few things, and try to break less things. This seems simple, but it's kinda hard actually. My biggest problem is focusing on one thing, and not getting distracted.

The way I solved this for myself, and it seems to be working, might be something worth sharing, so here we go.

Look at it as a performance problem in software

When a user reports a performance problem, they almost always report it in a qualified, but not quantified statement: "loading the transactions screen takes forever".

In solving performance problems, we measure a system under load. This is called profiling. The profiler lists the tasks that take the most of a resources cpu time for example. We then select the biggest offender. Then we dive into the stack to find the single lowest level function call that is causing most of this (over)use of resources. Then we fix only that function and run the test again.

Even in software it's typically not possible to design a test that exactly replicates real world future usage. So it is important to understand the performance problem well, so that we measure the right things to optimise for.

I propose to do a similar thing in real life when setting tasks for oneself. Life is also a complex system that we might optimise, isn't it? We change things, and these changes have effects. My goal is to spend my time changing things with the maximum impact towards my goals.

In the real world problem reporting is pretty much the same as in software projects. Example: "NFT's are worthless and produce CO₂ for no good reason". This statement seems obviously true, but it is not useful. As a fixer of things, you can observe an overwhelming amount of such problems, and you need to find exactly one of them to do exactly one thing about before you can take action. Let's look at a couple of statements to see this problem.

• NFT's are worthless and produce CO₂ for no good reason

• Dodge RAM's are worthless and produce CO₂ for no good reason

• Skiing is unnecessary and produces CO₂ for no good reason

• making long lists in blog posts is … all right, you get it now.

These are all things that some people might want to do, they might be perceived useful on a personal level (fun, convenience, workout). But we might easily agree that they are harmful to the environment, and seem non-essential at least. So we can take actions to reduce their negative effect on our planet. But which one should we work on to first? And what should be the first action? In order to decide on the first question we need to know which one is the worst. And to do this we need to quantify all of them.

How to quantify?

Quantifying is work, and some times when we ask people to help quantify something, they get defensive or even unpleasant. It seems to be common belief that if something is qualitatively bad, and reported, someone else is obliged to fix it. As a developer, you'll inevitably find yourself being shouted at by an incompetent manager if you refuse to prioritise fixing a bug before properly reproducing it and estimating its undesired effect. But in order to be effective, we must quantify and then prioritise the right thing.

I only have one body and one life, so I can do only a few things, one at a time. I need to know which one to do first.

In my first year of studying physics in the university, we had a class on estimation. When doing experiments, it's impractical to calculate every expected result in detail. So we usually get started with an educated guess (for which scientists have much nicer words usually). In the experiments, sometimes weird things happen and then we need to figure out what they mean. Otherwise we can't explain our measurements. To figure out why the weird behaviour happened being good at estimations is very helpful. In that class, we estimated how long it took to build a pyramid and how many people worked on it. With no other input than the previous sentence! It boggled my mind that this was even remotely possible, but it is, and more than half of the class was less than an order of magnitude off from the number that people specialised in this with a PHD in archeology agree on. Let's try some estimations.

How much CO₂ is emitted by NFT's?

First we just check if someone already did the work. 20 seconds and a search engine leads this long article on the subject. Unfortunately there's some red flags there, most importantly the statement that Etherium is PoW, which is no longer true. Etherium.org states that the total carbon footprint of the Etherium network is 870 tonnes of CO₂. That sounds more reasonable. Since that's not a very high number, I won't refine this estimate of an upper bound before I find that all other issues have a lower footprint. On to the next one.

How much CO₂ is emitted by Dodge RAM's

It's hard to find many articles on this, because RAM dealers and Dodge have done their SEO homework. We'll have to work this out ourselves. One RAM uses about three times as much fuel as a Kia Picanto (no link here, because I don't want to help their sales). Let's assume about half the kilometers driven with RAM's could also be driven by a Kia to reach the same result (single person going from A to B without towing anything heavy). Let's assume each RAM drives 200.000 km over its lifetime. So each RAM wastes around 5000 liters of petrol over its lifetime. There are about half a million RAM's sold per year in the US, so lets assume around 1m world wide. Each of these sales eventually attribute to those 5000l of wasted fuel. This boils down to around 10 million tonnes of CO₂.

We should also do this for the other issues before deciding on what to fix first, but you get the point here I guess.

Apart from quantifying the size of the problem itself, we should also quantify the effort cost of the solution. In either case here the cost is negligible (just don't buy it), but in some cases, like replacing all coal power plants with solar or wind, the effort will be significant. In that case the estimation should definitely include also these costs.

My conclusion for this comparison would be that we can ignore the NFT's for now, and decide to die on the hill against RAM's first. This is in no shape or form an argument that NFTs are a great idea, but it's a great argument against being distracted by them. NFTs are useless and worthless, maybe. But they are mostly harmless, definitely when compared to RAM's.

How to know which problem to quantify first?

Of course the world doesn't consist of four neatly comparable problems that you need to pick one out of to start with. A typical software project has hundreds of bugs open, and there's millions of those projects to choose from. Then there's also real world problems like hunger, fascism, inequality, environment, …. It's overwhelming to even think about the amount that would be on the list, let alone trying to estimate each of them in a comparable quantity (including different kinds of costs). So what's next after I publish this article for little old me?

What works for me is to find a big audacious goal, and keep that for a few years. Then slowly zoom in to pick subproblems to quantify and dive into. I keep doing this until I recognise something I can physically touch with my body and influence that way. Then I make it as likely as possible for that influence to have a ripple effect and influence other people to do the same. The action of writing this article is a way for me to put this into words, and help myself find the discipline to keep doing it (instead of lying on the couch overwhelmed by the brokenness of the universe). I hope it helps you a little as well.

To fill the list of problems to work on is tricky. How do we make the list is not too long, or important items are missing? In software we monitor systems that we deem high risk. We also simply listen to users reporting problems. Then, based on our mission and goals, we select a problem to fix. This is usually based more on feelings than on meticulous analysis. We want to feel good about our product, so we make sure the users don't hate it and it doesn't emit smoke and flying cogwheels when it shouldn't. There's a lot of fuzzy logic here, and that's fine with me. It's clear that this adapted trick from performance optimisation is not the full story. Each individual and organisation should make decisions on what problems are fundamentally worth looking at, and which are not before we even prioritise them. A remote software company like squads should not be optimising the recipe for apple pie, even though this is a very important issue.

It's very important to align yourself with a mission and goals, and not only listen to others that want you to take action. If you don't do this, you can be distracted into fixing something that doesn't do anything towards what you find important. Maybe I'll write more on that later.

Let me know if you have tips and tricks on this line. I'm always looking to learn how to trick myself into being more effective and less likely to get overloaded. Have fun, and don't forget to take a break ;)

My next physical action will be breakfast by the way :)