Good lord, I'm not glad.
It was horrible. Because it wasn't about "figuring things out for yourself." I mean, if the answer was available in a programming language or library manual, then debugging was easy.
No, the problem was you spent 95% of your debugging time working around bugs and unspecified behavior in the libraries and API's. Bugs in Windows, bugs in DLL's, bugs in everything.
Very frequently something just wouldn't work even though it was supposed to, you'd waste an entire day trying to get the library call to work (what if you called it with less data? what if you used different flags?), and then another day rewriting your code to use a different library call, and praying that worked instead. The amount of time utterly wasted was just massive. You didn't learn anything. You just suffered.
In contrast, today you just search from the problem you're encountering and find StackOverflow answers and GitHub issues describing your exact problem, why it's happening, and what the solution is.
I'm so happy people today don't suffer the way we used to suffer. When I look back, it seems positively masochistic.
>I'm so happy people today don't suffer the way we used to suffer.
TBF Ali bugs in some framework you're using still happens. The problem wasn't eliminated, just moved to the next layer.
Those debugging skills are the most important part of working with legacy software (which is what nearly all industry workers work in). It sucks but is necessary for success in this metric.
My point wasn't that the bugs don't exist anymore. Obviously they still do.
My point is that I can frequently figure out how to work around them in 5 minutes rather than 2 days, because someone else already did that work. I can find out that a different function call is the answer, or a weird flag that doesn't do what the documentation says, or whatever it is.
And my problem of it taking two days to debug something is eliminated, usually.
I don't know that it's that much easier today. I ran into lots of odd issues with Next.js and authentication and there wasn't a whole heck of a lot of useful info out there about it. Github does help, but you have to wait for the devs to reply.
There are tons of obfuscated Java jar libraries out there that are not upgradeable that companies have built mission critical systems around only to find out they can't easily move to JVM 17 or 25 or whatever and they don't like hearing that.
>My point is that I can frequently figure out how to work around them in 5 minutes rather than 2 days
Guess I'm just dumb then. I'm still taking days to work around some esoteric, underdocumented API issues in my day-to-day work.
Guess you missed my use of the words "frequently" and "usually", which I intentionally used instead of "always".
I guess I should have used "frequently" and "usually" when describing that I constantly run into problems relating to API's that cause mini-rabbit holes.
The thing is these API's are probably just as massive as old school OS cosebases, so I'm always tripping into new landmines. I can be doing high level gameplay stuff one week. Then the next week I need to figure out how authoring assets works, and then the next week I'm performing physics queries to manage character state. All in the same API that must span 10s of millions of lines of code at this point.
It's true that the time figuring out the buggy behaviour would now be less, but the buggy API doesn't go away only, because it exists on Github. If you would be able to change the source code now, you would've been able to fix it back then.
All the while having some dolt of a PM asking for status updates.