I think it's much better to say "Don't ask for solutions". There is enormous benefit in figuring out a solution, and flexing those mental muscles is really impo

I think it's much better to say "Don't ask for solutions". There is enormous benefit in figuring out a solution, and flexing those mental muscles is really important, but I think that it's also very reasonable to talk with a mentor or co-worker about a problem and be given some tools (mental, software, or otherwise) to help work through a solution. I think that good mentors and senior developers default to this approach even when they are asked for solutions, at least those who are invested in growing the capabilities of their teams. Looking at my personal experience, I'm one of the two senior developers on our 10-person team, and I'm typically the person that our junior and mid-level developers approach with any questions they might have. We have two developers on our team who started about a year apart, both of them have networking backgrounds and had no personal or professional development experience before joining our team. Our newest developer who is very motivated to grow and learn and wants to figure everything out for himself- give him a problem and he'll run off and you won't hear from him again until he has a solution and a war story about the three other approaches he tried before he arrived at this best of all solutions. The other developer did and still does ask for a lot of help, but the question is always "how do I learn about this". The first developer is still awful. He constantly falls victim to the problem of unknown-unknowns, and while his solutions are frequently clever they often are completely obviated by a small bit of knowledge about computer science, or of a common tool, or of a common development practice. Eventually when you see what he's come up with you can point out how something that already exists could have solved the problem, and there's even a bit of benefit to his understanding why things may be done in a certain way, having run into some of the problems they solve himself during his implementation- but the overall rate of progress is incredibly slow and as often as not after investing so much effort into his solution he fails to see why another approach would be better. The second developer has grown into a very skilled developer remarkably quickly, and I think it's because while they both have the tendency to shave yaks and crawl down rabbit holes in search of knowledge, the second developer has been willing to ask what the most profitable yaks to shave would be, how to best crawl down the deepest rabbit holes, and where to find the obscure bits of knowledge that you might not run into without the arcane search phrase incantations that seem to only come about with a lot of experience and a bit of luck.