[keithnz]

It's not terrible advice. You mentioned SICP, funny thing is, years ago when I put someone on to SICP, next thing you know in our production code we started getting these weird ass recursive functions..... Also had similar issues with Design Patterns, all kinds of overly engineered class structures started popping up. On the side of ALAN, I used to work with guy who did a lot of machine vision research, he coded everything the way he knew how for years, and he was super productive doing it. I didn't really like the code. But he got stuff done. Having said all that, learning stuff is still good, practicing stuff on non critical code is the next step.

Taking some lessons from BJJ ( Brazillian Jiujitsu ), when you compete, you go in with your A game, the things you have practiced, the things you have made work over and over again, your high percentage moves. Over time, you add things into your A game as you gain experience in making those techniques work. You may occassionally find yourself in an odd situation which some "new" technique is screaming to be used and you might try it out. But usually, when you encounter a situation you don't really know, you start working at getting the problem to change to something you do know, then throw your A game at it.

I think programmers should understand what their A game is.

[daemin]

I would gather though that the best way to learn new things is to apply them and use them in the code. That's the only way to get seasoned and find out when and where to use these things (like design patterns, recursive functions, etc).

It sucks when this is happening to a production system, and then maybe it's a mentoring & leadership problem instead.

[overgard]

You lost me at "next thing you know in our production code we started getting these weird ass recursive functions...". I don't mean to be mean, but recursion is pretty fundamental to a lot of algorithms, and it sounds like the SICP coder was just writing stuff more advanced than you were comfortable with.

[human20190310]

Anything that is more advanced than necessary is too advanced to be comfortable with.

[keithnz]

think you kind of missed what I was saying, I was the one recommending, having already done a bunch of functional programming, and thought SICP was a nice intro ( at the time ) to functional programming. But they didn't quite get it and their code was a weird mish mash of OO and weird uses of recursion with badly thought out (stateful ) functions.

[Lutger]

Might also be an inappropriate application of recursion in a language where loops are more common. I've seen people who learn new stuff go overboard with clever code in production that is less readable for their peers.

Recursion shouldn't even be considered advanced though, just like classes and first class functions. I'm all for making code as boring as possible, but to me understanding at least these concepts is a requirement of entering the profession of software development.

[albertoCaroM]

Sometimes recursion is the good solution, For example a back-tracking solution is more simple with recursion than without it.

[threatofrain]

But doesn't putting somebody on SICP in the hopes of helping them learn functional programming (is that SICP's concern?) sound to you as... aspirational advice? The book is as famous as it is infamous.

[keithnz]

the point is more that anything you learn, you often want to try out the new toys. But those toys aren't your A game and we haven't learnt the lessons yet of applying things to achieve real results, so often that can skew our productivity. Whole new frameworks can leave us completely incapacitated when we hit the edges of what is commonly done until we either dig through things ourselves or find someone to answer our questions.