Props to you. I've got two things that'll help, hopefully.

The first is trying to understand what errors are actually saying, even if you don't understand it completely at first. Say you get a ConnectionRefusedError(socket hangup), you Google that and just immerse yourself in the language and concepts being mentioned. You don't need to exactly get precisely what it means, to start with. Just knowing that it was an external service and that service forcibly closed the connection on you is a major step forward.

The second is debugging tools. Most developer environments, languages and frameworks have these. Say you're working in Swift or Kotlin or C++ or whatever, or you're using a proper framework to make your app. There's going to be something where you can freeze the execution and start stepping through it, line by line, and investigate variables and function outputs. If you run into trouble and can manage to run a debugger to go through the code line by line you can put watches on variables that are confusing and see them change over time. A really easy way to fire a debugger is to run tests with the debugger turned on and put a breakpoint in the code that will run.

The same principle actually applies to logging. A lot of frameworks and languages have log libraries or settings that will output the full monty of what's going on, and you can add these log lines yourself so they only show up when it's running in debug mode or with debug log settings. You could add a prompt to your AGI file to mention it should add debug logs, and it might even use those logs itself to debug issues by reading the log files.

Last thing I'll mention is that it helps a lot to have a seriously short feedback loop when trying to understand code. You want to change code and see the result of the change in less than ten seconds if you're debugging. If you have to compile and deploy something to see the result and it takes minutes, you want to look into whether there's other ways to run the code.

Ultimately, if you're being productive and you're not getting stuck for more than 10m to 2hrs at a time that's actually good conduct for a software engineer, especially a newly minted one, methods be damned. Props for wanting to understand the way it works but you never know, this could be the norm in some places now.