Deconstructed recursion

The last two weeks of assignments in my classes have been about recursion.  This week for our assignment we had to rewrite a linked list class so that each method used recursion.  

Adding and Removing made the most sense.  It was easy to find the bad cases and then call the method again.  I used a helper function for each method, made it easier to comply with other parameters from the assignment.

I'm still confused on the formatting of some things.  I had used a few else statements after the if statement that was funding the base case, but had to remove most as it was causing an endless loop.  

I also had to rewrite the reverse method a few times until I remembered to include a temporary counting variable.  Will have to find more leet code problems to test myself going forward.

Overcomplicating Recursion

As I study recursion and begin applying it in my homework, I notice some similarities, or at least tenuous connections between recursion steps and troubleshooting.

IT support should work on the basis of elimination of a class of issues at a time, until you drill down to the root issue.  I recommend reading DevOps Troubleshooting by Kyle Rankin for more on this subject.

Recursion looks to eliminate a choice, usually between two options, until it returns your root cause, or base case.