Not quite binary ping-ponging, but I've have often found rotating through writing functional code, writing documentation of what's desired, and writing test cas

Not quite binary ping-ponging, but I've have often found rotating through writing functional code, writing documentation of what's desired, and writing test cases very helpful in defining "What should each function do? What parameters and context should each take? How should the overall solution be structured?" in cases where that isn't entirely clear (e.g. first pass at solving new or complex problems). Sketching functional code (and/or pseudocode/stub-only functions) lays down a concrete hypothesis about what the code (or at least its key parts) should be. Writing docs fleshes out the aspirations and expectations (including helping you define non-goals and not-yets). Writing tests demands thinking through edge, corner, and other hard cases. Each informs one's understanding and intuition about the other two, and almost automagically drives gap analysis. "Whoops! Haven't thought about/implemented/documented/tested that yet! Let's go do that now! (or at least put it on the TODO list)" It's a strong tight loop. Would also suggest you don't limit your "write tests" phase/work to pure "does just one thing" unit tests. You don't initially want full end-to-end tests that assume and require everything's working in order to start testing, but some of the tests can and probably should venture into the "requires multiple components interacting" space usually called "integration tests." I think of that happy middle ground / hybrid between pure unit and full integration tests as "functional tests" or "functional block tests" where the size/complexity of the functional blocks under test have more leeway than unit testing/TDD dogma usually allows.