Critical of Approaches

It shouldn't be a surprise to anyone that I was working on my GoLang project when I found something that, although relatively simple, I still Googled for the exact syntax to use. I wanted to trim out leading spaces from a string.

Seeing as this was a programming related question I was in no way surprised when the link I was given led back to StackOverflow. The question was asked almost precisely as I had worded it, too. Nice!

However, the question had downvotes, and the first comment was somewhat snarky; "Seriously... you didn't google that, did you ?"

I'm assuming this is a reference to a question of whether the user had checked the GoLang documentation, since the Go language has quite a bit of (rather terse but straightforward) documentation on the standard and common library functions in the language. The poster said that he did, but didn't understand what the cutset was as referenced in the trim function.

The problem as laid out in the question was that the asker had a question while working on something and laid it out as he had searched for it (which apparently was really good for Google indexing, since I found it near the top of search results.) They had found the reference documentation and didn't understand something as it was worded there. Rather than ask about that step in the troubleshooting process, they backed up a step to the original question, and asked it. And was mocked for it.

It reminded me of a damned if you do, damned if you don't situation I've occasionally run into. Recently I've been paying conscious attention to asking questions framed as an end goal, and not framed as a step I'm on in troubleshooting or finding a solution.

For example, asking about changing a particular block of code in a phone server would yield a response of, "What are you trying to do?," and sometimes that would lead to a, "What you might actually want to do is XYZ." The person had  better way of achieving the results I'm looking for, or know of gotchas in what I was trying to change.

Framing the question in terms of a step along the path to what I think is the way to achieve a goal means I might be going down a rabbit hole. Working with someone more knowledgable means I might find a solution that benefits from their experience.

The problem is that learning the how of something takes more time. In many job situations, this isn't appreciated; you need to solve a problem and move on. You're kind of penalized if there's a perception that you're using company time to do something like "learning." I've had conversations on this vein with someone in the Geeking After Dark podcast, where I described a mentoring or learning program sponsored by an employer would be beneficial for an employees professional growth, but he argued that if it's not a benefit to the employer and took up work time it's not something worth doing. Learning has to take place on your own time, and it's commonly expected that employees improve themselves, even in a professional capacity, on their own.

So when do you seek learning how to fish versus the expectation of asking for fish? You're asking a question because you need to solve a problem, and you're penalized for trying to learn the how while the giver of the fish...in this case StackOverflow...has community members that penalize you for not asking how to fish.

Maybe there's not a straightforward solution to this, unless there are more people willing to give an answer while expounding on the solution so the asker has an opportunity to learn. All the poster really needed in this example was a restatement of the documentation in a more learning-friendly manner. Perhaps the asker isn't asking a how-friendly question. But that doesn't mean someone can't answer it as such.