I've read several books and learned through experience that optimizing code to the point where it is inscrutable, or coming up with an extremely fast but extremely complex solution to a problem is not desirable when working in teams, or even when you're working by yourself and have to understand your clever solution some time later.My question is, should recursion be treated in the same manner?  Does the average programmer understand recursion easily and thus one should use it with impunity, or does the average programmer not understand recursion very well and one should stay away from it for the sake of overall team productivity?I know there are simple answers of, Any programmer who doesn't understand recursion isn't worth a grain of salt, so don't worry about them but I was wondering if you all had some real world experience you would like to share that would illuminate the issue more than the opinion I just mentioned.
Is recursion an instance of being too clever when programming?
maintenance;teamwork;recursion
Does the average programmer understand recursion easily and thus one should use it with impunity, or does the average programmer not understand recursion very well and one should stay away from it for the sake of overall team productivity?I'd say that the average programmer understands recursion perfectly.  Indeed, if the programmer has done a degree in Computer Science or Software Engineering it is pretty much guaranteed.  Granted, there are some very below average programmers out there, but you don't want them on your team.In this case, the distinction between an average and a good programmer is knowing when to use recursion and when not to.  And that depends on the problem being solved AND the language being used to solve it.If you are using a functional programming language, recursion is a natural and efficient solution for a wide range of problems.  (Tail recursion optimization rules!)If you are using an OO or plain procedural language, recursion can be inefficient and can be problematic due to stack overflows.  So in some cases you would choose an iterative solution rather than a recursive one.  However, in other cases, the recursive solution is so much more simple and elegant that the (possibly more efficient) iterative solution would be the too clever one.  (For example, if the problem requires backtracking, building or walking trees / graphs, etc, recursion is often simpler.)