Step 1, define the problem.
Step 2, probably a good idea to try to reproduce the problem.
Redefine if you need to and now you might have some direction.
And so on.
Don't assume you know what it is and just try to fix it on the fly.
well, I did get that far. It’s sorting through all the files, functions, variables, and objects that makes me tend to short circuit these days.
At that point it becomes more specific but im completely lost I will:
"Well this button calls this function then..."
neeno16006d@stackodev I can relate so much to this. When looking at a codebase I'm not familiar with for the first time I get overwhelmed with the code, trying to understand what everything does. The start is the worst part, but after like 2-4 hours of frustration and feeling lost I start understanding how stuff fits together and I slowly calm down.
Generally I start somewhere that implements a functionality I'm familiar with (like a button that I know what's for) and from there on I start following the code. Sometimes just start at the main file of the program, where everything begins, and then follow the code, but that doesn't work very well if the code is written in a framework I'm not familiar with, because there's a lot of stuff happening behind the scene.
ArtOfBBQ1346dTotally normal imo. Reading and understanding other people's code is really difficult even if they're good and you are too. They have their style and habits which may seem alien and insane at first but probably have real merits also. Once you thoroughly understand what they were doing it'll probably be easy to debug
If there's some skill level where this becomes trivial I haven't seen it.
I think it's also ok to put some emphasis on actually enjoying the process. When you started coding you probably didn't beat yourself up like this; if anything you were probably overjoyed when something actually worked. You probably enjoyed that process and that's how you ended up here, so let's get away from all this pressure nonsense and back to that mode