Michael Richter wrote a blog post criticizing Stack Overflow, in part, for giving fish to users instead of teaching them to fish. From his blog post:
I'm not a Java programmer. I've only ever briefly programmed in Java professionally. I hated the experience and I hate the language. I certainly don't consider myself a Java expert. Yet I managed to get the bulk of my points from Java. How is this possible?I thought this was timely, given that I was working on a sample project for the past month or so, and finding myself having to learn (or re-learn) several bits and pieces of the programming language I was using.
It's possible because I did what many of the people whose questions I answered (and got points for) should have done for themselves: I saw a simple Java question, hit Google, read briefly, then synthesized an original answer.
Mr. Richter's primary complaint in this regard is that people are asking for specific answers to specific problems in terms of "Give me teh codez!" instead of receiving instruction on how or why a solution works (or is more or less proper). Indeed, I believe his post is saying that the point system used to gamify Stack Overflow actually encourages the quick shotgunning of a pithy "here's teh codez" response to a question.
In other words, "Here's the fish. You don't need to know how to get them yourself."
There are perhaps several aspects of Stack Overflow (and the Stack Exchange network) that can encourage that kind of succinct answer. Many users have bemoaned the points awarded for being the first to submit a working reply to a user's question. But in thinking about it, are users asking how or why something works in the first place, or are they asking how to solve a particular problem they're encountering as they're working on a project?
I think that it's more the latter. When a user runs into a roadblock, they turn to Stack Overflow to find a solution. They're focused on the problem at hand, not the learning behind it. Not unless someone tries to engage them in steering towards a better way of doing things, and if it doesn't answer the question or encroaches on engaging in a discussion, there is a risk of flags being thrown.
They're not coming to SO to learn as much as they're coming to have a problem solved.
Is this the most beneficial approach?
I frequently find myself thinking to one of my favorite quotes from Star Trek II; Kirk says to Saavik, "You have to learn why things work on a starship." To better master the craft...the art...of programming, you should understand why the "right" way is the "right" way. I suppose it's the difference between a cook and a chef.
I think not all programmers want to be chefs.
Learning how and why things work isn't something that can be done quickly or in easy to digest chunks, not when you have a project that has to be completed in a reasonable timeframe. A question and answer site is not necessarily the best framework for learning the kind of knowledge that comes from a virtual apprenticeship.
There are resources for the kind of learning that gives you understanding more than a packaged answer. There are websites like Codecademy to teach programming. There are bloggers who post information on various quirks in a programming language. There are books on the philosophy of programming and application design.
And if there were specific questions about these resources, questions that elaborate or clarify what one of these resources is trying to teach, I'm sure that Stack Overflow (or the Programmer's site) would be willing to answer.
In other words, Stack Overflow can teach you to fish, if you ask how to fish instead of for the fish. Perhaps the complaint that SO is full of people handing out direct, contextless answers is more a reflection of what the community wants rather than what the site can give.
In most cases just getting the answer is enough to fix a roadblock someone encounters, and SO is a great resource. When a programmer is interested in learning why things work, there are other resources, and they need to take the time to dive in and investigate the puzzle.
No one will volunteer to mentor you. It just doesn't seem to happen.
There were times when I ran into issues during my project. In one case I was opening a text file and reading lines in to add to an array. It contained a logic bug; while the input "<> nothing" apparently choked on an empty line in the middle of the file, so it would stop reading input partway through without warning. I had to change the test condition so that it would look for the end-of-file mark. The examples I found for working with text files had the former (how else would I have hit upon that syntax?) in the code samples.
In retrospect testing for the end of file makes more sense than testing for "nothing." But then again, it was working. Or it seemed to be working. What the hell does .NET consider "nothing?" Where is this appropriate as a use case?
At the time I didn't think much of it. I was working against my self-imposed deadline and I wanted to fix this bug. At some point I might revisit this seemingly non-useful "nothing" used in my file test to find out what the language actually considers "nothing."
This is probably a silly example. At the time I didn't think anything of it, and now I'm probably overthinking it. But sometimes the things we think are inconsequential or have trivial answers are actually misguided. The thing is this isn't the only weird thing that I hit along the way, and the fact that other people were using this particular syntax in their coding examples means that others could hit the same glitch I did.
Sometime I should ask about the problem on Stack Overflow. Or I should troll around searching for some clarification. I'll have to invest time, actual learning time, into understanding what happens.
But for now, I fixed the initial bug. Sometimes that's good enough.
No comments:
Post a Comment