I think that TDD is in a way "sketching" for programmers, you draw the outline (the expected results), and then you fill in and refine the details one by one to make the code work. When dealing with the complex code I also have a habit of structuring the code with comments first: I write a comment for each step in the flow (like a subtitle for that block of code: e.g. parse input, calculate this, get that, output result, etc.), and only when that logic as a whole makes sense I start to implement the actual code below the comments one by one. I find this very helpful to visualize the logic flow.
Comments
I think that TDD is in a way "sketching" for programmers, you draw the outline (the expected results), and then you fill in and refine the details one by one to make the code work. When dealing with the complex code I also have a habit of structuring the code with comments first: I write a comment for each step in the flow (like a subtitle for that block of code: e.g. parse input, calculate this, get that, output result, etc.), and only when that logic as a whole makes sense I start to implement the actual code below the comments one by one. I find this very helpful to visualize the logic flow.