May 5, 2023Why debugging with passive mind waste you more time
I don't know when we'll learn. You know the moment when you're too frustrated to deal with any more errors, and you're just doing things blindly in the hope of getting output or the thing you were wishing for. Sadly, the reality is that it would take us more time that way than to just step aside. If you're burnt out, you might as well take 30 minutes off. But to me, it feels like running from the problem. Everything I do, even when praying, gives me different solutions. I make a mental list of different solutions, but sometimes they work, and most of the time, they don't, so I have to think through the problem again.
Just as I was planning to load test the older version of the backend that was handed over from another team and the newer refactored, or should I say revamped, version that I'm very proud of, I passively planned like this: I'll first test the one endpoint that was bugging out team due to the loads of data it sends to the application's homescreen, and it was way too slow. I first tested it in production, but due to my lack of knowledge, routes were not being logged, and I had no idea whether those requests were being parsed or being timed out. I let a very heavy test run, which involved running multiple requests from 10, ramping up to 100 for up to 600 seconds. Somehow, the test ran for more than an hour, and the results were terrible - about 90% of the requests failed.
However, I then shifted to test the revamped version. I spun up a new EC2 instance with T3 resources to ensure that system resources wouldn't be a problem during the test. I tried different tests with different scenarios. The thing is, when I finished the test, I realized that I didn't need to have any test setup on the production server. I could've tested the older version on the same server I tested the revamped version. It was just a matter of checking out a Git branch. That was my passive approach, which caused some downtime for users as the server had to restart to change the instance type. Upon rebooting, some Nginx configurations messed up, and the initial server stopped. These were quick fixes, but still, "not touching the production server" is probably the best choice in all scenarios until you're confident with your commits.
From now on, I plan to thoroughly think about anything I want to do, and then see what approach I could take to best achieve it. It'll take some time to get used to, but it'll be for the better.
Photo by Eilis Garvey