It's also important to ask questions well: "here's what I did and what I expected, but this happened instead. Here's what else I've tried and researched before asking you, and these are the things I'm not sure about".
Forming a good question often leads to the answer in of itself. By writing it down and emailing it instead, the person can answer it at their own leisure, and the response can be easily shared with the whole team to learn from.
Even better, if that fails, you now have a copy you can easily post to a github issue or mailing list (or stack overflow, if you prefer).
When I have trouble with something, instead of reaching for colleagues, google, or stack overflow, I just read the manual(s) top to bottom, multiple times if necessary, or the source code, or write prototyping test cases.
Even if it doesn't always solve my problem, the things I learned in the meantime always pays back later. The downside is I inevitably become the person to ask for help, and I'm always told "How do you know so much?", and I tell them exactly that, but they don't seem to get the hint, I'll see them again in the near future. I've even been previously termed as a kind of "real life stack overflow".
I suspect it may be a generational issue -- those of us who were left to solve difficult problems without the help of the internet have developed methods that do not include google and stack overflow.
Anyway, I do ask for help. I've studied destructive forces in software development teams, my current hypothesis is that ego is behind them all.
1) Asking good questions is important, the process of forming a good question will often lead you to your solution.
2) Giving good answers is also important. You could show the person asking the question how to solve their problem, or you could show the person how to find the solution to that problem.
3) Even if you are asking good questions and getting good answers, there is still value in having to force your way past a problem to a solution. Not only does it teach resilience, but the struggle to find the solution can teach you many things that are tangential to the problem
1) Absolutely
2) Teaching is ideal. Except...
3) Too many people today don't care about anything but the answer. They are lazy and/or uninterested in learning and growing. Take for example one of my In-Laws and their dishwasher, they a) never knew about rinse aid and b) stack the dishes too full and/or on the wrong rack resulting in half the dishes coming out still dirty. They think they are saving time and "winning". They can't be bothered nor have they ever considered reading the owners manual that came with the thing. If more people would RTFM that people have taken time to compile... It only takes 5 or 10 minutes.
When you frame the question to ask so someone for help sometimes you tend to get the answer yourself. I've been practicing rubber duck debugging for a while and it has proved quite successful.
Documentation is cheating; you'll never become a rockstar developer that way! Most writers will try to answer the most common questions that a dev will have about their code; this is just as bad, if not worse, than asking them questions yourself. You need to read the source code to truly understand.
I shudder at all the young minds that have been warped by the 'USAGE' statements in man pages; back in my day, we used to have to either guess at which arguments did what, or stare at the devs' custom, mangled argument parsing functions to figure out how to use a program.
LOL, that seems to be the case with node projects today... there are plenty of modules that work great, and have some documentation, but when you want to use something in a different way, you have to dig into it.
If it were related to my job: that is my title was "Sr. Java Programmer", I would read it all, and/or maybe some books depending on my current level of familiarity. Given the size of Spring documentation, I would shortcut to my answer as necessary, but make a recurring appointment with myself to spend at least an hour each week reading the rest of the documentation.
If it were not, that is my title was "Web Administrator", I wouldn't read it at all -- it is not important for me to know Spring. I would ask the java developers for help and move on with my day, instead reading the documentation for jBoss or WebSphere or whatever is relevant.
Chosing what to spend your time learning is a critical function of your career. Imagine if you had spent time learning Flash, Delphi, VMS/VAX, Novell Networking, or any other now-legacy languages or technologies. It's a bit of a betting game, really.
Forming a good question often leads to the answer in of itself. By writing it down and emailing it instead, the person can answer it at their own leisure, and the response can be easily shared with the whole team to learn from.
Even better, if that fails, you now have a copy you can easily post to a github issue or mailing list (or stack overflow, if you prefer).
When I have trouble with something, instead of reaching for colleagues, google, or stack overflow, I just read the manual(s) top to bottom, multiple times if necessary, or the source code, or write prototyping test cases.
Even if it doesn't always solve my problem, the things I learned in the meantime always pays back later. The downside is I inevitably become the person to ask for help, and I'm always told "How do you know so much?", and I tell them exactly that, but they don't seem to get the hint, I'll see them again in the near future. I've even been previously termed as a kind of "real life stack overflow".
I suspect it may be a generational issue -- those of us who were left to solve difficult problems without the help of the internet have developed methods that do not include google and stack overflow.
Anyway, I do ask for help. I've studied destructive forces in software development teams, my current hypothesis is that ego is behind them all.