If you've ever been on duty at a company with a lot of customers and 24/7 activity, chances are that you already found out the hard way what makes an alert actionable.

An alert is actionable when the first person who sees it can immediately answer three questions:

• What broke? – a clear, human‑readable message, making it obvious what the problem is, business wise.
• Where did it break? – for which specific entity(ies) and in which situation the problem happened.
• Why did it break? – whenever possible, the precise error condition that leads to the unexpected situation.

If any of those bullets are missing, the engineer's next best move is usually to add logs, redeploy, and hope the error happens again. That is wasted time.

So how do you make sure your alerts are actionable?

Curiously, dependency injection is not something that we often see in the JavaScript ecosystem.

Still, it's a powerful pattern that can help you make your code more flexible and easier to test, if implemented properly.

After a lot of iterations, we've come up with a dependency injection system that works well for us at Orus. The point of this article is not to cover exactly how dependency injection works, but rather to share our learnings in building it.

Unions and discriminated unions are great tools that can make the code flexible, while keeping the complexity to a low level. But tiny differences in the style of the code that uses them can make the difference between robust code, and bugs waiting to happen.

In this article, we will dive into two patterns that can help us make our code more future-proof.

But before "future-proofing" our code, let's remember that many technical debt nightmares originate from unfortunate attempts to be future-proof.

So let's be clear about what we mean by future-proof code.

Dealing with errors is an essential part of software engineering.

Defining and having strong guidelines on how to handle errors will make your life easier when developing features, but also, and maybe more importantly when things go wrong!

At Orus (where we try to reinvent professional insurance), over time, we tailored an error strategy that works well for us and that we think could be useful to share.