How To Be A Good Guru

In her engaging UKOUG presentation on being a newbie Lisa Dobson devoted a large chunk of time to Being A Good Newbie. That is, how to post questions on Oracle-related lists in the manner most likely to elicit a helpful response. We might summarise this advice as don't poke the tigers.

Lisa didn't have the OTN Forums on her list of, er, lists but we get a lot of newbies posting questions there. Partly it's just location, location, location: the Oracle site is the obvious first port of call when you need help¹. Also, it is not a forum where the really big beasts - the Oak Table chaps - visit and the level of discussion hardly ever descends to hex dumps of block headers and other such esoterica. Hence newbies are perhaps less likely to feel embarassed about posting simple questions. This is obviously a good thing but it does impose a burden on us soi disant experts who volunteer to answer their questions. So, in homage to Eric Raymond's seminal guide to list etiquette for newbies I am modestly proposing some advice to would-be responders. And, yes, I know I still regularly break these guidelines.

How to Answer Questions the Smart Way

#1. Don't answer questions to which you don't know the answer

Obvious really, but it's very easy to think you know something about the database that is no longer true, or maybe never was. For instance it has been a long time since anybody asserted that explicit cursors performed better than implicit ones, but people still proferred this advice long after it had ceased to be true. Be sure that if you do post something factually incorrect your peers will gleefully expose your bloomer to the wider world. It is better to post the right solution second than be first with a wrong one.

It is perfectly okay to research an answer. Indeed, one of the benefits of answering questions on the forums is that we discover stuff we didn't know. Questions coming from out of leftfield can tell teach us interesting (and sometimes even useful) things about how the database works.

#2. Explain yourself

Eric Raymond advises newbies to approach technical gurus in a supplicatory fashion. They are supposed to treat lists as resources of last resort, to kowtow before the collective wisdom and then present a detailed description of their problem, including complete specifics of environment and configuration, plus all the things they've already tried and all the manuals, whitepapers, etc they've already read, before humbly beseeching us for the merest crumb of assistance. Of course the ungrateful wretches never do this but we should still respond graciously.

It's not enough to dash off the correct answer. Consider whether its correctness will be obvious to the questioner. If not, try to explain why it's the correct answer. That way there's less chance that the questioner will be posting an almost identical question next week. Whenever possible include a link to the relevant part of the manual. Linking to a specfic heading in a chapter is better than just linking to the Table of Contents, but the manual is not always tagged the way we would like. Similarly, if you need more information, explain what else you need to know and why you need to know it. If you want (say) an explain plan and you suspect they don't know what that is, link to the manual.

#3. Give as little assistance as necessary

The most effective form of learning is discovering things for ourselves. Teaching someone how to diagnose their own code (use SQL> SHOW ERROR, look up the error, check the syntax in the online documentation) is better than just rewriting their code for them. Not least because in rewriting the code we are likely to break some business rule we do not understand.

#4. Show your workings

When answering a SQL related post it is always best to include a worked through example. Take a tip out of Tom Kyte's practice: use cut'n'paste from SQL*Plus to demonstrate that what you have asserted is in fact the case. This is a corollary of #1.

If, for reasons of time or environment (for instance you do not access to a database) it is acceptable to post untested code, provided:

• you indicate it is such;
  
• you think an untested code sample is more helpful than no code sample at all;
  
• you think it is probably correct. Heh.
  

Nothing exposes a poseur faster than a piece of code that doesn't even compile, so make sure you cover yourself.

#5. Use humour judiciously

Many people using the forums do not have English as their first language. Humour does not always travel well between cultures. Some questioners will not be expecting humour in a work context². Furthermore, even amongst English speakers, humour can be difficult to spot without the non-verbal signifiers that accompany barroom banter. In particular irony is a tough one to pull off. Still, humour is a Good Thing and can liven up some dry reads so by all means be witty (if you can - lame jokes are, well, lame). It is helpful to use emoticons to signify that your preceding line was intended humourously, even if they are a debasement of the high standards of English literature. Jane Austen never posts on Oracle lists anyway :)

Oh, and sarcasm is right out (see #6).

#6. If you can't say something nice don't say anything at all

Just like your mother told you.

There are no stupid questions only stupid answers. If someone has posted a question you don't think is worthy of an answer then don't bother answering. Remember: you're a volunteer, there is no compulsion, you are choosing to answer the question. So, the person is not wasting your time by asking a stupid question, you are wasting your own time by typing a stupid (angry, sarcastic or belittling) answer. By all means explain what is wrong with the question, show how it could have been phrased better or request more details. If some newbie has posted "my code doesn't work", ask them to describe the observed behaviour, to explain the difference from expected behaviour and to paste in the error message and callstack (if appropriate).

If somebody seems to be particularly unreasonable - posting an URGENT!!! question on Saturday and then whinging in follow-ups that nobody has responded - feel free to explain to them that you are a volunteer, this is a free service and there is no SLA. In fact, if they want an answer within a set timeframe they should stop being so darned cheap and spring for a support contract. Also, if I suspect the poster is a student looking for me to do their homework I always ask for a course credit (Not being American I have no idea what this means).

#7. Avoid jargon, baffling acronyms and idiolects

Fnord. This is just another way of demonstrating your superiority over the OP. Of course, like wit, you can use such stuff if you think your audience will get it. Alternatively, embed a link to the Jargon Dictionary, although this rather undermines the point of using abbreviations. LOL.

#8. Never never never just respond with RTFM. Not ever.

Telling some newbie "RTFM" is an act of pure arrogance. It just feeds the respondent's ego without helping that questioner learn anything, except maybe not to ask for help in the forum again. Barbara Boehmer taught me this one. Keep in mind that the Oracle FM is huge; there are dozens of books and the search engine fronting the online version ain't that great. At the very least, post "RTFM" and a link to a relevant part of TFM. That way at least they will know where to go the next time they need to find out something.

STFW is at least as bad and arguably worse. Googling for information about Oracle problems takes a lot of skill, not just in filtering queries but in knowing which results can be trusted. There are plenty of snakeoil merchants out there. (You may think you know who I am talking about but there are others too).

#9. Meditate on eternity

Other people will read your posts in the future, because they will come up in search results. Obviously if these people are using the OTN Forum search engine they'll probably be after an answer to some completely different question but Google also indexes the OTN Forums. So try to make your answers suitable for a wider audience. Besides, as Jakob Nielsen observed in another context, your future boss may be reading.

#10. Keep your newbie mind

We were all newbies once. We are all still newbies in some dimension of the database, it's just too big for one mind to know everything. Even Tom Kyte occasionally farms out questions to Sean Dillon, Cameron O'Rourke et alia. So the next time you find yourself about to type a withering riposte to some "dumb" question just remember: one day, in some forum or other, you will ask a dumb question and an arrogant, big-brained geek is going to squash you like a fly.

---

^{1. Unfortunately this means people do assume their questions will be answered by Oracle employees and therefore there is some SLA we have to meet. In fact most OTN forums have little or no active Oracle participation (the HTMLDB, Developer and JDeveloper forums being honourable exceptions).}

2. Here is my favourite example (the words are approximate, this is from memory). The questioner ask a generically "stupid" question, "How can I improve the performance of my database?". A wag responded (using the UBB [code] markup so it looked authentic):

ALTER SYSTEM SET GO_FASTER='TRUE'
/

The original posted replied, "I tried this command but it failed due to illegal option". Which is funny but also rather cruel.