One trick you can use is to test things interactively with the perl debugger. When faced with a complex and potentially confusing deeply-nested data structure (especially one provided by a third party library), I often run the code in a debugger, and set a breakpoint on a line where the data structure is in scope. I then interactively attempt to read it until I have found the correct syntax to get down to the part I want. I then paste that bit of syntax into my editor.

That way if I get confused and write $thingy->{foo}->[3]-­>{wobble}-­>[4]->() when I should have written $thingy->{foo}->[3]-­>{wibble}->{wobble}-­>[4]->() The perl debugger will tell me, and I can adjust things until you I it right. This is much better than the program crashing and I have to keep re-running it with different syntaxes until it is correct.

I find this technique is especially useful when used with third party libraries that I did not write that return objects with access methods to get things out. Often if you can't remember the name of the access method you need, you can guess as it will often have the same name as a likely looking key in blessed hash you get back.

One trick to remember when examining large deeply-nested data structures, especially anything that contains doubly linked lists or trees is to limit the depth when you use x $objRef in the debugger. For example when working with DBIx::Class result objects, I usually do x 3 $rowObj and get about 20 lines of output. If not I get about 1000 lines of output filling my screen.