It's all about the context

July 19, 2022

What always bothered me about self-help books is that most of them are contradicting each other. Some books scream go faster, while others whisper to slow down.

It took me a few years to understand why both approaches are correct.

A backstory

I studied social sciences, and I was interested on how creativity works and how to unlock it. A few lessons in we got a simple graph with the relationship between performance and pressure.

If there's not enough pressure, you start half-assing it. If you have too much pressure, you get anxious. Both are bad for performance.

There's a sweet-spot in the middle. Just enough pressure for best results. The key is finding the balance between not enough and too much.

After I've read Malcom Gladwell's David and Goliath, where he has a whole chapter on the inverted U curve (the graph above), I understood why all of those self-help books bothered me.

For me, they focused on the wrong thing.

It's all about the context

Most advice can be reduced to two extremes. Either do something more, or do something less. Either go faster, or go slower.

While this is perfectly valid advice, it tells you nothing about your context. The context here is the if that comes before the advice.

If you're too slow, go faster. If you're too fast, slow down.

Let's say you find yourself on the left side of the curve. Adding additional pressure will improve your performance. But doing the same when you're on the right side will be disastrous as it will decrease your performance.

Most of your effort should be spent on figuring out where on the curve you are, as that's your context. The position of that blue dot will tell you to either do more, or do less.

Context is never static

Your context is always changing, sometimes by external forces, other times by your own influence. The consequences of those changes might mean that the things that brought you success in the past might start hurting you, as the context switched sides.

For example, you were a solo developer and your time to delivery was fast. But you didn't write tests and the coding style was of your own invention. Being fast was productive.

Now you're working as a part of a team. The things that made you an amazing solo developer are making you a bad team member. Being fast stopped being productive. Being consistent and predictable become productive. The context has changed. The blue dot changed sides.

But what does this have to do with software engineering?

Software engineering revolves around context.

Having a single 1500-line file that was coded in a week, and you have to use FTP to deploy it, does sound like a horror show. But if that file has been running for years without any issue, and is making money, that's a success.

On the other hand having a properly architectured app, with tests, and 99.99% uptime, does sound like a joy to work on, but if there's no users, all that effort was wasted. That's a failure.

It's all about the context.