DEV Community

Zach
Zach

Posted on

Toy Problems - The Best of Times, The Worst of Times

One day after a minor triumph, see: one-shotting a toy problem, I was taken down bittersweetly in another toy-problem square-off.

'Bittersweet' because the solution was (and remains) tantalizingly close - white-boarded meticulously, tested in Chrome snippets, and recently, producing promising results.

I first attempted allAnagrams during our hourlong end-of-day toy problem block. The recursion approach came to me pretty quickly, and so did the white-boarding. The devil, my friends, is in the details.

Two things that I've learned, or learned more deeply, on this problem: closures and assignment.

Closures

Yes, closures do exist in recursion.

My allAnagrams strategy centers around entering for-loops that call a recursive inner function. My assumption was that at any given iteration of the loop (i=2 for example) that after going however many layers deep into the recursion, the function would revisit that loop and pick back up at the next i++ and continue; in this case, at i=3. And then once this loop terminated, if it was nested, it would pick back up wherever it was entered, for instance in a parent loop at x = whatever.

I'm not sure that closures is the right term, or the right way to think about remembering where in the loop (ie. which i) to pick-back up from. But that's the idea. It's always satisfying when your carefully-considered assumptions are validated.

Persisting Data

I might even call this the tricky thing about recursion. Moving data deeper inside of the recursion in a way that is aligned with your strategy and then managing that data when you spin back out of the recursion, going from the inside outwards.

I ran into an issue when, while looping over an array, I spliced that array, permanently removing one of its items. I then passed that smaller array into the recursive inner function, with the intention of repeating this process until I hit the base case of array.length === 0.

Well, the array that I spliced was being iterated over in the for-loop, and when the function unwound back from the base case to pick back up with iterating over that array...there was no more array. I had spliced its contents out of existence, prematurely terminating the for-loop.

The immediate lesson here was to copy the array - and then splice the copy so that the destructive recursion-splicing would leave the original array intact to be looped over when the recursion unwound back up to that level. The larger lesson is the be hyper-aware of what's happening to the data - because the data's all you got baby.

Grand takeaway

While the goal is absolutely to solve every toy problem (and to do it elegantly, and quickly, and...), really the goal right now is to improve my problem-solving process and to gain familiarity with the common patterns in the problems and solutions. If those are improving, then everything is working exactly as they should. The point isn't to be really good right now. It's to be really good when I need to be really good.

Top comments (0)