I've been doing the programming-forum thing for about 9 years now. Funny story: I originally started answering questions online in the hopes of drumming up contract jobs, as I was freelancing at the time. After almost a decade and tens of thousands of cumulative posts jammed into the tubes, I have yet to earn any business whatsoever from my efforts. Not a single contract. I quit freelancing a few years ago, but the irony of that never fails to amuse me.
In any case, when you spend that volume of time and attention on helping literally untold hundreds of people with their problems, you begin to see patterns. Lots of patterns. It doesn't take long for the same questions, same discussions, and same arguments to recur... over, and over, and over.
The old, slightly cynical, hardened forum veterans will sigh and point back to past threads. Sometimes, they'll post a comprehensive list of discussion related to the topic. Very rarely, the starter of the discussion will read through the history, learn his lesson, and move on silently, strengthened by the direction of the more senior member.
Usually, though, things just go straight to hell. A couple of people will always show up for certain discussions - their pet issues, hot buttons, whatever you want to call it. They'll get in and say the same stuff they say every time. Then some other newbies will show up and say something, sincerely believing that they are original and insightful - but the veterans have heard it before.
Sooner or later, patience dwindles, people get tetchy, and someone's toes get stepped on. The thread may flare up briefly into a flamefest before being locked, or before people just quit caring and don't read it any more. But they always die.
Then the thread gets buried, disappears into the black void that is "everything beyond page 1", and is never heard from again... until three days later, when some other bright-eyed newbie comes along and brings up the same topic. Naturally, nobody learns from last time, and everyone has to run through the cycle again.
This is the life cycle of technical forums, and (to an extent) social forums as well. I've been watching them for quite a while, and these patterns occur and recur in every forum with consistency and bewildering frequency.
There are days when helping people with programming questions on the Internet seems like a punishment once reserved for Sisyphus. Those are usually the days when I decide to stop reading forums for a while.
Forum veterans around the tube-o-sphere know exactly what I'm talking about. These phenomena are neither strange nor unfamiliar to anyone who has invested any significant time in a programming community online. But for all the cumulative brain-power that has been directed at this problem, there is as yet no solution.
There are certainly proposed solutions, and chief among them is the invocation of the all-powerful Google. (Once upon a time, before Google became synonymous with the word, the invocation used to just be "search.") If only these newbies would learn to search, we'd say back in 1998. If they'd search before posting, they'd find all the easy answers, and the volume of pointless questions would drop off quickly. Then, the forums would be reserved for the more interesting and deep discussions, and we'll all be happy.
I see this same exact sentiment echoed today, on GDNet itself in fact. The terminology changed a bit in the past 9 years, but the idea didn't: if all these new posters would learn to search, our forum quality would improve.
This, I am sad to say, is a tremendous fallacy, and reflects a serious underlying issue in how we collectively perceive programming education.
The problem is, quite simply, that newbies don't search because they don't know how. More accurately, even if they do search, they probably don't find the answers they want.
Somehow, the Internet has perpetuated this idea that the ability to search intelligently is orthogonal to deep understanding of a domain. This is a ridiculous belief. In actual fact, properly leveraging Internet search utilities (Google, forum searches, and so on) requires three things:
- You have to know the right words
- You have to know how to recognize the answer
- You have to know how to work a search engine
As a veteran of the Internet, it's tremendously easy for me to take these things for granted. I've seen my seniors and peers do the same, for a long time. We are all terribly mistaken.
Knowing the Right Words
This point was driven home to me in a painful way last night. There's a particular bit of low-level hackery I wanted to do on the Windows platform, involving keyboard hooks. The details are not important; suffice it to say, I've done this before, and know it is possible.
What I didn't remember was how exactly to do it, or where I'd learned the trick in the first place. I spent half an hour on Google trying fruitlessly to dig up something I knew was out there. I knew some of the right terms, even a good part of the answer, but couldn't find what I wanted. I couldn't think up that one magical keyword that I'd stumbled across the first time, and therefore couldn't find an answer that I'd already found before. I ended up solving the problem a different way.
Now, I'm no slouch when it comes to searching the Internet. I've watched a lot of my friends hunt and peck on Google, and in all candidness I think it's fair to say that my understanding and familiarity with search technology is much better than theirs for the most part. In fact, I only know of one person who is consistently better at finding things on the web than I am.
If I, a web veteran of a decade and a proficient searcher as well as a competent programmer cannot find an answer to a relatively simple question - an answer I've found in the past - how can we expect newbies to solve their own questions on Google?
Consider a typical programming newbie: someone who doesn't know the programming jargon, hasn't memorized arcane corner cases of dozens of APIs, doesn't deeply understand the interworkings of modern computer software and the causal relationships between various aspects of programming, has never seen the answer to their question, and maybe isn't even sure there is one. Just for kicks, they don't understand that Google doesn't speak English and can't parse their question meaningfully; the semantics of keywords, PageRank, and search engine optimization are totally unknown to them.
How is this person ever going to have a chance in hell of finding the answer they need?
Recognizing the Answer
This is a nice little bit of Zen puppetry. It turns up in many forms: you can't learn something until you already almost know it, the fuzzy understanding threshold, the Blub paradox, and so on.
The gist of it is simple, but profoundly important: you can't find the answer if you can't recognize the answer.
Imagine this coversation:
InquisitiveTwelveYearOld: I learned square roots today!
WiseElder: Cool... what's sqrt(25)?
InquisitiveTwelveYearOld: Uhmm... let's see... five!
WiseElder: Very good.
InquisitiveTwelveYearOld: Hey, I wonder... what's the square root of -1?
WiseElder: i
WiseElder, satisfied with his disbursement of knowledge, leaves the conversation.
InquisitiveTwelveYearOld: WTF?
The poor kid is now totally screwed. He's been given a perfectly correct answer, but has no means by which to understand it. He doesn't even recognize that it is the answer; for all he knows, WiseGuy is just messing with his head and being a jerk. Well, screw you, WiseGuy, and screw math... I'm just going to go play football.
And thusly we lose another bright young mind who could have done amazing things.
Working a Search Engine
This is not as easy as it may sound to people with lots of web experience. In fact, it's a particularly difficult skill in itself. The complex interplay of advertising revenue, PageRank whoring, system abuses, and mysterious algorithms makes searching a shot in the dark at best. We tend to think of Google as the gateway to all Internet knowledge, when in fact it's little more than a digital roulette game. We only persist in using Google as the de facto standard of searching because the roulette wheel happens to (seem to) pay out fairly often.
In reality, though, we never know what we might have missed. Sometimes the best results are on page 2, but if the results on page 1 are marginally satisfactory, would you bother going to page 2? If you get a mediocre answer on page 1, do you ever click through and read the stuff on page 2 to see if a better result is available?
What about page 34?
What about pages that aren't listed on Google? (Of course, some would theorize that the non-Googleable Internet does not really exist.)
If that isn't enough to drive home the seriousness of the problem, ask yourself one last question: if you can't even tell a good answer from a bad one, will you bother going to page 2?
What if you try to search, but only get back 10 pages of irrelevant crap, because you tried to do the one search Google can't do?
That is precisely the position we leave our newbies in when we tell them to search before posting their questions.
The Road to Hell is Paved With Bad Advice (and Stupid Sayings)
Clearly, the common advice to "search first" is misguided. A true newbie cannot search in any meaningful way, and has little hope of truly solving their problem by searching.
Worse, searching tends to yield popular but very bad answers to particular problems (*cough* I'm looking at you, CodeProject), which actually make this advice deadly. The Wise Elder recommends a search; the Newbie does a search and finds Bad Advice. The logical conclusion for the Newbie is that the Wise Elder endorses this Bad Advice, which probably is not the case.
Six months later, the Newbie (now promoted to Novice) comes back and asks another question; the Bad Advice has left him in a nasty position and he's not sure what to do. Wise Elder returns; he doesn't remember Novice, but Novice definitely remembers him. Wise Elder perceives that the real problem is Bad Advice, and sternly corrects Novice and his horrible misguided ways.
What sort of impression must that leave on the newbie?
I don't know how common that situation really is, at least in that particular form, but it happened to me back in my own newbie days - and still does, on occasion, when I venture into areas that I know nothing about.
So the world is broken. How do we fix it?
There's something that I think could cure this problem. It's not an easy solution. It doesn't scale. It isn't efficient, and it isn't much fun. In fact, it's more or less a pain in the arse - for some of us.
I remember back in my very, very early days of programming, before I understood algorithmic complexity notations and software design and coherent abstraction and all that cruft. Back when all I wanted to do was draw some cool animations on the screen.
I had a tiny bit of contact with the demoscene world, and I loved it. I wanted to do my own. But all I had was a musty copy of QuickBasic and a worn book that seemed to be aimed more at accountants and statisticians than graphics and game programmers.
This was before the Internet, so I had no way to find other people who could solve my questions. I learned a lot of bad habits (and just plain didn't learn lots of other things) because I had no one to learn from. The one thing I wished for most during those early days was for a Guru to come down from the mountains and mentor me, teach me everything I needed to know.
Gurus, as you may know, are in critically short supply, and generally like their mountains an awful lot. Therefore, I naturally didn't get my wish. I ended up having to fight to teach myself, often at great expense (for a high school kid), and usually with rather dubious results.
I've spoken to a few other programmers and heard similar stories. But, most tellingly, I'm watching a few friends start to learn programming themselves. The sentiment appears again, and again, and again - why can't someone just sit down and explain all this crap in some way that makes sense?
Just the other night I walked one of those friends through solving a trivial physics simulation problem. It was vector math - stuff I do in my sleep these days (quite literally) - and very simple equations at that. But this friend simply couldn't see how to solve the problem.
He emailed me the example code his professor had given as a guide for the assignment, and I immediately knew why such a pathetically trivial question had become an insurmountable obstacle: the professor's code was utterly, thoroughly, and completely terrible. In a five line function I spotted well over a dozen idiotic habits and decisions before I gave up counting - I had to close my eyes and look away lest the horror of it melt my retinas into my brain.
After I convinced my friend to ignore the professor and just think through the problem on paper, and write his own code, he solved it in a blink.
What newbies need isn't Google-fu. What newbies need is mentors. Twenty-first century high technology needs a good solid dose of eighteenth century apprenticeship.
Mentoring 101
To be quite frank I really don't know how mentoring works in practice. I never had a real programming mentor, and I've never really been one to anyone else. But it seems clear to me that therein lies the solution to the problem of educating new ranks of programmers.
I do know that mere "teaching" is no help. I've seen enough people struggle through abysmally bad "programming classes" to know they don't work. I've tried to teach a couple of them and swore to never again touch that quagmire of hopeless foolishness.
Call it cheezy or frivolous if you like, but I think the Zen method works pretty well. The masters should take the students in, a long-term and in-depth relationship. The student should be free to ask questions and explore on their own; the master should do what he can to facilitate this.
However, on a regular basis, the master should pose exercises to the student. These should be deep questions that require real learning to solve, not just busy-work (as is the norm in programming classes). Even better, these should follow the spirit of koans: oblique, obscure, and subtle questions that have no obvious or clear answer; they are not meant to be solved, but pondered, the master knowing that as the student considers the problem his understanding will be broadened.
Most importantly, though, we need to get away from the forum model for teaching newbies. It doesn't work. It goes well beyond "too many chefs in the kitchen" - it's too many chefs in a kitchen, which is also being used as a petting zoo, and simultaneously doubles as a nuclear physics research center. It's just totally screwed. Conflicting advice, an overabundance of perspectives, and disagreeing opinions are not things that newbies are prepared to handle, and yet we thoroughly drown them with such noise.
Instead, we need to take a leaf out of the old master/apprentice model: the master's word is law to the apprentice, at least until he gains mastery himself. There is only one master, to avoid the extra noise of conflicting views until such time as the student is prepared to handle them.
Of course this raises the all-important question of quality control. Without alternative views, how will we ensure that students are taught well? Just as in the days of apprenticeship, this problem solves itself rather elegantly. The masters who teach well will produce new masters. The results speak for themselves. Reputation is a powerful tool for the mentor model.
This is not a new idea. Mentoring of new programmers is a theme I've heard echoed widely, from the legendary Brooks, the Pragmatic guys, and even a few of my own seniors. Interestingly enough, it seems to come consistently from people who have attained true mastery, and are best qualified to speak on the matter. (And every now and then some hapless joker like me says it, too.)
Perhaps it is time we stopped simply talking, and put this model into practice. Where might software go, if it is helmed by a new generation of masters?
