We’ve heard that observability is important to understand what is happening in production. But carving out the time to add instrumentation to a codebase can seem daunting, and is often treated as a separate task to writing features. This means that we end up instrumenting for observability long after a feature has shipped, usually when there’s a problem with it and we’ve lost all the context.

What if we instead treated observability similarly to how we treat tests? We wouldn't submit our code without a test. Let’s do the same with observability. Treat it as part of the feature while the code is still fresh in our mind, with the benefit of being able to observe how the feature is behaving in production.

We’ll cover practical ways to instrument during development so it feels like a natural part of the development workflow. Because if you know how to log, you know how to trace.