Inverted Debugging

Forget the Docs, There’s Gold in Them Thar Code

We exist in a reality where, at best, documentation lives on the periphery, can’t be trusted, or even worse: non-existent. The development community has done a great job of banding together to help each other solve the many problems we face, but finding that perfect Stack Overflow post may not ever surface. Relying on the world to help you solve your problem is not a long term solution, so break those habits and trust in yourself as I attempt to show you the light that I call Inverted Debugging – the process of using code, not documentation to solve your development problems

Inverted Debugging Forged by Decades of Fire and Source Code

Look back on your development journey, think about how often you are faced with an error message and a stacktace – how much of your precious time has spent digging through google results, reading documentation, posting on forums, calling up your developer buddies only to feel defeated; I wouldn’t be surprised if I’ve spent an entire year of my life hoping the world will unblock my work. Ask yourself:

Why did I put my trust on anonymous internet dwellers over my own abilities?

I am not a better developer than you, no matter what you think reading my words or looking through my work; I simply have spent over 20 years getting beat down, frustrated, and defeated – eventually had had enough of it. The world wasn’t going to change, but I can. What was in my control was how I approached problem solving holistically: documentation is abstracting function into words, code on the other hand is concrete, logical. Through Inverted Debugging, you will have a greater understanding of frameworks, design patterns and appreciation in yourself.

RTFL: Read the Fucking Logs

An error is thrown and your first instinct is it’s a grenade – fight or flight. Why? That error is trying to communicate with you! Fight the frustration instinct, take a breath and read the logs, the message, the stack trace; take it in and look for a pattern, look for key code points, examine the call stack. You were just gifted the map to buried treasure! It’s possible the answer is right there on the screen, but more often than not you are about to grab a shovel and start digging.

Yes It Must Be Said…

Check dependency versions, perhaps a breaking change was introduced via an unpinned library. It is a quick was to rule out the obvious.

Embrace Your New Code Archeological Role

When unearthing your problem, you don’t want to miss the root by digging too fast, too deep, or impatient. Work backwards through the stack trace, examine the logic – think about edge cases, or missing checks.

Once you start to understand the code beneath your code, you become exposed to examples of good architectural patterns, or patterns to avoid. Almost second nature, you stop seeing languages – it becomes a small refresher on language syntax before you’re on your way.

And as Always…

You are not an imposter, in fact the goal is to elevate.