How I Met Your Debugger

Kids, today I’m going to tell you how I met your debugger.

You see, back in the summer of 2010 I was fresh out of Uni and trying to prove myself at my first job – a small startup in the world of retail. My first major assignment was developing an Explorer add-in to a web client with a Java backend. So when I had to debug it, my process would be as follows: set a breakpoint at Eclipse for the backend server, and a breakpoint at Visual Studio for the Explorer add-in. Then, run both apps, trigger the UI, break, see the frame, step, hit the backend, break, step and repeat.

First loves and monoliths

With time I grew accustomed to this multiple IDE debugging. I didn’t even mind having to switch keyboard shortcuts whenever I jumped from debugging my client to debugging my server. I guess you could say that was my first true debugging experience. And you never forget your first.

Years later I found myself working in a large enterprise company, adding features and mostly, well, debugging legacy features in a huge .NET based monolith, with some Java Add-ins. One of the biggest challenges there was figuring out where even to begin investigating a new problem. Where do I place my first breakpoint? Who the h#$% built this code? What was he thinking?

But with time I learned that my first love was here to help. I figured that if I set a breakpoint as early as possible, and patiently step into the code (switching from VS to Eclipse and back again), I will eventually “Grok” the application. Indeed, with enough time, patience, and a powerful debugging tool, I was finally able to get the hang of what was going on and learned that there is no better way for me to get into someone else’s code, or break down a monolith, than simply stepping in and out through the code.

Flying too close to the cloud

But this love wasn’t meant to last. Eventually, we decided to get rid of the monolith and soar up to the cloud. We were going to break the backend into microservices, deploy in AWS, do everything by the book. But then I realized that just like Silicon Valley’s Richard Hendricks, I just couldn’t do cloud.

How do you debug a process that doesn’t run on your machine? Set a breakpoint in a piece of code that mustn’t stop? Attach your IDE to a service that hasn’t spawned yet? I was completely lost and watched with admiration as my friends threw log lines into the air, being able to tell from a million nearly identical lines just what the problem was and how to fix it. Much like Roger Murtaugh, I figured out that I was getting too old for this s#$%. I thought I’d never debug again, and was willing to leave my mechanical keyboard and geeky T-shirts behind to complete the transition into product management.

More years have passed. Eclipse and Visual Studio were replaced by Word and Powerpoint, and apart from the occasional scripting demo or HTML-based documentation, I didn’t write much code. I was even close to deleting my World of Warcraft account. I thought it was all over for me.

The one with the yellow umbrella

And then I met Rookout. And it was just like debugging for the first time. I felt at home, in the comfort of an IDE. It allowed me to look at my code, set a breakpoint, and let the debugging flow. With Rookout, I could debug a local application or one that runs in a docker container, or in my staging or production environment; I could even debug several parts of the application written using different frameworks, all in the same debugging session. Set a breakpoint, trigger the app, see the debug data, Grok your application from inside. Just as I always did.

So that’s my story. That’s how I met your debugger. If you’re experiencing a similar heartbreak, you don’t have to transition to product management just yet. Your next debugging solution may be just under your nose, holding a yellow umbrella.

Happy debugging! 🙂