¿Cómo hacer preguntas de manera inteligente?

Resumen

A veces cuando nos conectamos en un foro,chat,blog,redes
sociales, etc; formulamos una pregunta que lamentablemente no
consigue repuesta, y no es que no tenga repuesta, si no que esa
pregunta está mal formulada.Aunque esto sea
quizás una cuestión más de dialéctica
que de informática, aquí les muestro a ustedes;
este artículo para como mínimo aumentar las
posibilidades de éxito de obtener una respuesta a sus
dudas informáticas.

1.
Introducción

En el mundo de los hackers, el tipo de respuestas
que obtengas a tus preguntas técnicas depende tanto de la
manera en que formules tus preguntas como de la dificultad de
desarrollar la respuesta. En esta guía se
enseñará cómo preguntar de manera que puedas
obtener una respuesta satisfactoria.

Lo primero que tienes que entender es que a los
hackers les gustan los problemas realmente com- plejos y
las buenas preguntas que les hagan pensar en ellos. De no ser
así no estaríamos aquí. Si nos proporcionas
una cuestión interesante te estaremos agradecidos; las
buenas preguntas suponen un estímulo y un regalo. Las
buenas preguntas nos ayudan a desarrollar nuestra
comprensión, y a menudo revelan problemas que
podíamos no haber percibido o en los que de otra manera no
habríamos repara- do. Entre los hackers,
"¡Buena pregunta!"debe entenderse como un sincero
cumplido.

A pesar de esto, los hackers tienen la
reputación de enfrentarse a las preguntas sencillas con
hos- tilidad o arrogancia. A veces parece como si
resultásemos hostiles a los principiantes o a los
ignorantes. Pero eso realmente no es cierto.

Lo que somos, de una manera no apologética, es
hostiles con la gente que parece no querer pensar o hacer sus
deberes antes de plantear las preguntas. La gente de ese tipo son
sumideros de tiempo – toman sin dar a cambio, desperdician
el tiempo que podríamos haber dedicado a otra
cuestión más interesante y con otra persona
más merecedora de una respuesta. A las personas de este
tipo las lla- mamos "perdedores"–y por razones
históricas a veces escribimos "luser"1 .

Somos, de largo, voluntarios. Robamos el tiempo de vidas
ocupadas para responder preguntas, y a veces nos sobrecargan.
Así que filtramos sin tregua. En particular, desechamos
las preguntas de quienes parecen ser perdedores para ocupar el
tiempo que dedicamos a responder preguntas de una manera
más eficiente, con los ganadores.

Tu´ no quieres ser uno de los perdedores. Tampoco
quieres parecerte a ninguno de ellos. La mejor manera de obtener
una respuestas rápida y eficiente es preguntando como un
ganador — como una persona con inteligencia, confianza en
sí mismo e indicios de que necesita ayuda con un problema
en particular.

2. Antes de
preguntar

Antes de hacer una pregunta ténica
en un foro, chat, correo electrónico o página web,
haz lo siguiente: Intenta encontrar una respuesta leyendo el
manual.

Intenta encontrar la respuesta leyendo
las FAQ.2

Intenta encontrar la respuesta
preguntándole a un amigo con más
experiencia.

Cuando hagas tu pregunta, destaca el hecho de que ya has
hecho todo esto; esto ayudará a es- tablecer que no eres
una esponja vaga y que sólo estás desperdiciando el
tiempo de los demás. Au´n mejor, destaca lo que
hayas aprendido a partir de estas cosas. Nos gusta responder a la
gente que ha demostrado ser capaz de aprender de las
respuestas.

Prepara tu pregunta. Piensa en ella. Las preguntas
precipitadas reciben respuestas precipitadas, o ni siquiera eso.
Cuanto más hagas para demostrar que has puesto pensamiento
y esfuerzo en resolver tu problema antes de pedir ayuda,
más cerca estarás de recibirla
realmente.

Ten cuidado de no hacer la pregunta equivocada. Si haces
una que esté basada en asunciones erróneas,
Hacker Al Azar seguramente te responderá con algo
literal e inu´til mientras piensa "Qué pre- gunta
más estu´pida…", y esperando que la experiencia de
obtener una respuesta a lo que has preguntado exactamente en vez
de a lo que necesitas saber te enseñará una
lección.

Nunca asumas que tienes derecho a una respuesta. No lo
tienes. Te ganarás una respuesta, si te la ganas haciendo
una pregunta sustancial, interesante y que haga pensar— una
que contribuya implícita- mente a la experiencia de la
comunidad antes que solicitar de manera pasiva conocimiento de
los demás.

1 Es una contracción de los
términos "user" (usuario) y "loser" (perdedor)

2 Frequently Asked Questions, una
lista de preguntas y respuestas comunmente usado para proveer
información a los usuarios.

Por otra parte, un muy buen comienzo es dejar claro que
puedes y quieres participar en el proceso de desarrollar la
solución. "¿Tiene alguien alguna pista?"
"¿Qué le falta a mi ejemplo?" y "¿Hay alguna
página que debiera haber consultado?" tendrán
más probabilidades de ser respondidas que "Publica por
favor el procedimiento exacto que debería seguir", porque
estás dejando claro que estás realmente deseoso de
completar el proceso si alguien simplemente te orienta en la
dirección correcta.

3. Cuando
preguntes

3.1. Elige el foro con
cuidado

Ten cuidado al elegir dónde planteas tu pregunta.
Seguramente te ignorarán o te tacharán de perde-
dor si:

Publicas tu pregunta en un foro en el que
se encuentra fuera de lugar (off topic)3

Publicas una pregunta muy elemental en un
foro en el que se esperan preguntas técnicas avanzadas, o
viceversa.

Publicas el mensaje al mismo tiempo en
foros muy diferentes (cross-posting)4

Los hackers descartan las preguntas inapropiadas
para intentar proteger sus canales de comuni- cación de lo
insustancial. No quieres que te suceda eso.

3.2. Escribe de manera clara respetando la
ortografía y la gramática

Sabemos por experiencia que los escritores descuidados y
chapuceros también piensan de manera desordenada y
chapucera (a menudo lo suficiente como para apostar por ello, no
obstante). Responder a pensadores descuidados y chapuceros no
recompensa; mejor estaríamos usando nuestro tiempo en
cualquier otro lugar.

Por esto, es importante expresar tu pregunta de manera
clara. Si no puedes molestarte en hacer eso, nosotros no podemos
molestarnos en prestarte atención. Aprovecha el esfuerzo
añadido en pulir tu lenguaje. No tiene que ser nada
estirado ni formal — de hecho, la cultura hacker valora el
habla informal, la jerga y el lenguaje cómico usado con
precisión. Pero tiene que ser preciso; tiene que haber
alguna indicación de que estás pensando y prestando
atención.

Deletrea correctamente. No confundas "its" con "it"s" o
"loose" con "lose". NO ESCRIBAS TODO EN MAYU´ SCULAS, eso
se lee como si estuvieses gritando, se considera poco "fino".
Si

escribes como un bobo medio analfabeto probablemente te
ignorarán. Escribir como un hax0r script kiddie de l33t es
el beso de la muerte absoluto y te garantiza que no
recibirás otra cosa que un silencio sepulcral (o, si
tienes suerte, un montón de desprecio y
sarcasmo).

Si preguntas en un foro en el que no se usa tu idioma
materno, obtendrás una cantidad limitada de avisos por tus
errores gramaticales y de ortografía — pero ninguno
añadido por tus argumentaciones chapuceras (y sí,
normalmente conocemos la diferencia). Además, a menos que
conozcas las lenguas de quienes te respondan, escribe en
inglés. Los hackers ocupados tienden a descartar
las preguntas en idiomas que no entienden, y el inglés es
el idioma de trabajo en la red. Al escribir en inglés
minimizas las posibilidades de que descarten tu pregunta sin
leerla.

3 Término en inglés que nos
quiere decir que está fuera de lugar

4 Es la publicación
(comunicación) de una pregunta a más de un foro a
la vez

3.3. Envía las preguntas en
formatos que sean fáciles de entedner

Si artificialmente haces tu pregunta
difícil de leer, tendrá más probabilidades
de ser ignorada en favor de una que no lo sea. Por
esto:

Envía el correo en texto plano, no
en HTML.

No
envíes correo en el que párrafos completos consten
de una u´nica línea por mu´ltiples veces.
(Esto dificulta responder sólo a partes del
mensaje.)

Tampoco
envíes mensaje codificados como MIME Quoted-Printable;
todos esos "=20" esparcidos por el texto son feos y además
distraen.

Jamás de los jamases esperes que
los hackers puedan leer formatos de documentos
propietarios como Microsoft Word. La mayoría (no todos,
algunos) de los hackers reaccionan a esto de igual manera que
reaccionarías tu´ ante un montón de
estiércol humeante volcado en el umbral de tu puerta,pues
trabajan con GNU/Linux.

Si
envías correo desde una máquina con Windows,
desactiva la estu´pida prestación "Smart Quotes"
(citas inteligentes) de Outlook. Esto es para evitar caracteres
de basura esparcidos por tu mensaje.

3.4. Usa títulos
específicos y con sentido

En las listas de correo o en los grupos de
noticias,foros,la cabecera del mensaje es tu oportunidad de oro
para atraer la atención de expertos cualificados en
aproximadamente 50 caracteres o menos. No los desperdicies en
balbuceos como Por favor "ayu´dame" (de "POR FAVOR
AYU´ DAME!!" ya ni queremos escribir ni hablar). No
intentes impresionar con lo profundo de tu angustia; mejor usa
ese preciado espacio para una descripción lo más
concisa posible del problema.

Estu´pido:

¡AYUDA! ¡El vídeo no funciona en mi
portátil!

Inteligente:

Cursor del ratón deformado con XFree86 4.1,
chipset de 1vídeo Nvidia MV1005

3.5. Sé preciso e informativo
sobre tu problema

Describe los síntomas de tu
problema o error con cuidado y claramente. Describe el entorno en
el que ocurre (máquina, S.O., aplicación,
etc).

Describe
la investigación que llevaste a cabo para acotar una
posible respuesta al problema antes de hacer la
pregunta.

Describe
los pasos de diagnóstico que llevaste a cabo e intenta
solucionar el problema tu´ mismo antes de formular la
cuestión.

Describe
cualquier cambio reciente en tu computadora o combinación
de software que pueda resultar relevante.

Hazlo lo mejor que puedas para anticiparte a las
preguntas que un hacker te haría, y para respon-
derlas antes de tu solicitud de ayuda.

Simon Tatham ha escrito un excelente ensayo
titulado Cómo informar de errores de manera efectiva. Te
recomiendo efusivamente que lo leas.

3.6. Describe los síntomas del
problema, no tus suposiciones

No es u´til decirle a los hackers lo que
tu´ crees que está causándote el problema.
(Si tus teorías de diagnóstico fueran tan fiables,
¿estarías pidiendo ayuda a otros?) Por esto,
asegu´rate de que u´nicamente estás
contándoles los síntomas de lo que va mal y no tus
interpretaciones o teorías. Deja que ellos lleven a cabo
las interpretaciones y pronuncien su
diagnóstico.

Estu´pido:

Me salen errores SIG11 durante la compilación del
nu´cleo, y sospecho que haya podido romperse un hilo en uno
de los circuitos de la de la Tarjeta Madre. ¿Cuál
es la mejor man- era de comprobar eso?

Inteligente:

Mi K6/233 ensamblado por mí con una Tarjeta Madre
FIC-PA2007 (chipset VIA Apollo VP2) con 256MB Corsair PC133 SDRAM
empieza a tener frecuentes errores SIG11 sobre unos 20 minutos
después de haberlo arrancado durante el curso de
compilaciones del nu´cleo, pero nunca durante los primeros
20 minutos. Si reinicio no se reinicia el reloj, pero si lo apago
durante la noche sí. Pasar toda la RAM a la
partición de intercambio no ha servido de nada. A
continuación….

3.7. Describe los síntomas de tu
problema en orden cronológico

Las pistas más u´tiles para averiguar
qué ha ido mal se encuentran a menudo en los
acontecimientos inmediatamente anteriores. Por esto,
deberías describir con precisión lo que hiciste, y
lo que hizo la máquina, hasta el momento fatídico.
En el caso de procesos por línea de órdenes,
disponer de un registro de la sesión (p.ej., usando la
utilidad del "script") y citando las veinte líneas o
así relevantes resultaría muy
u´til.

Si el programa en cuestión tiene opciones de
diagnóstico (como -v para prolijo) intenta pensar cuida-
dosamente en elegir opciones que puedan añadir
información de depuración u´til para la
transcripción.

Si tu mensaje acaba resultando muy largo (más de
cuatro párrafos), puede resultar u´til comentar el
problema de manera sucinta al principio y luego hacerlo de manera
cronológica. De esta manera, los hackers
sabrán dónde mirar al leer tu mensaje.

3.8. No solicites que te respondan por
correo electrónico o en privado

Los hackers creen que resolver problemas
debería ser un proceso pu´blico y transparente
durante el cual un primer intento de respuesta puede y
debería corregirse si alguien con más conocimien-
tos percibe que la respuesta es incompleta o incorrecta.
Además, obtienen parte de su recompensa por responder al
verse que son competentes y que poseen conocimientos suficientes
por parte de sus iguales.

Cuando pides una respuesta privada, estás
interrumpiendo tanto el proceso como la recompensa. No hagas eso.
Es elección de quien responde hacerlo en privado
— y si lo hace, normalmente es porque piensa que la
pregunta es demasiado obvia o mal planteada como para resultar
interesante para otros.

Hay una excepción limitada a esta regla. Si
piensas que puedes recibir una gran cantidad de respues- tas muy
similares por el tipo de pregunta, entonces las palabras
mágicas son "mándame las respuestas por correo-e y
haré un resu´men para el grupo". Se considera
cortés ahorrar a la lista de correo o al grupo de noticias
una gran cantidad de respuestas sustancialmente idénticas
— pero evidentemente tienes que mantener la promesa de
resumirlas.

3.9. Evita las preguntas
insustanciales

Resiste la tentación de cerrar tu consulta con
preguntas semánticamente nulas como "¿Puede ayu-
darme alguien?" o "¿Hay alguna respuesta?" Primero:
si has escrito la descripción de tu problema de manera
medianamente competente, ese tipo de preguntas añadidas
sin más resultan, como poco, supérfluas.
Segundo: al ser supérfluas, los hackers las
encuentran molestas — y probablemente te devolverán
respuestas de una lógica impecable aunque
ignorándote como "Sí, pueden ayudarte" o "No, no
hay ayuda para ti".

3.10. Concluye con una breve nota sobre
la solución

Envía una nota tras haber resuelto el problema a
todos los que te ayudaron; hazles saber cómo acabó
todo y agradéceles de nuevo su ayuda. Si el problema
atrajo el interés general en una lista de correo o grupo
de noticias, entonces será apropiado publicar la nota
allí.

La nota no tiene que ser larga ni desarrollada, un
sencillo "Pepe – que al final resulta que lo que fallaba era el
cable. Gracias a todos. – Jose Luis" será mejor que nada.
De hecho, un resu´men corto y agradable es mejor que una
larga disertación a menos que la solución requiera
de cierta profundidad técnica.

Además de ser cortés e informativo, esta
especie de seguimiento ayuda a todos los que te asistieron a
sentir una sensación satisfactoria de cercanía al
problema. Si tu´ no eres un hacker, créete que ese
sentimiento es muy importante para los guru´s y expertos a
quienes pediste ayuda. Los problemas que acaban sin resolverse
resultan frustrantes; los hackers desean verlos resueltos.
El buen karma que aliviar ese picor te hará ganar te
resultará de mucha ayuda la próxima vez que
necesites plantear una pregunta.

4. Cómo
interpretar las respuestas

4.1. RTFM y STFW: cómo decirte
que la has "Chorreao" seriamente

Hay una tradición antigua y venerada: si obtienes
por respuesta un "RTFM",5 la persona que lo envió piensa
que deberías haberte leído el puto manual. Casi con
total seguridad estará en lo cierto. Ve y lee.

RTFM tiene un familiar más joven. Si recibes como
respuesta "STFW",6 quien te lo envía piensa que
deberías haber Buscado en La Puta Web. Casi con toda
certeza tendrá razón. Ve y busca.

A menudo, quien envía una de estas respuestas
está contemplando el manual o la página web en
cuestión mientras escribe. Estas respuestas significan que
piensa que:

1. La información que necesitas es
fácil de encontrar,

2. Y aprenderás más si buscas
tu´ mismo la información que si te la dan "digerir"
en bandeja de plata.

Esto no debería ofenderte; segu´n el
estándar de los hackers, se te está
mostrando cierto respeto (aunque áspero, no lo neguemos)
al simplemente no ignorarte. Deberías agradecer la extrema
amabili- dad.

5 RTFM, acrónimo de "Read The
Fucking Manual",es decir;"Lee el Jodido Manual."

6 STFM, acrónimo de "Search The
Fucking Web",es decir;"Busca en la Jodida Web."

4.2. Si no entiendes…

Si no entiendes la respuesta, no devuelvas
inmediatamente la solicitud de una clarificación. Usa las
mismas herramientas que utilizaste para intentar resolver tu
pregunta original (manuales, PUFs7 , la Web, amigos con mayores
destrezas) para entender la respuesta. Si necesitas pedir una
clarificación, intenta demostrar lo que has
aprendido.

5. Sobre
cómo no reaccionar como un perdedor

Hay bastantes posibilidades de que te
equivoques más de una vez en foros de la comunidad
hacker

– de maneras detalladas en este
artículo o similares. Y se te dirá exactamente en
qué te equivocaste, posiblemente con profusos detalles. En
pu´blico.

Cuando esto sucede, lo peor que puedes hacer es
lamentarte por la experiencia, denotar que te han asaltado
verbalmente, pedir disculpas, llorar, contener la
respiración, amenazar con pleitos, quejarte a los jefes de
la gente, dejar la tapa del baño abierta, etc. En vez de
eso, esto es lo que tienes que hacer: Superarlo más nada.
. .

Los estándares de la comunidad no se mantienen
por sí mismos: los mantiene la gente que los aplica
activa, visiblemente, en pu´blico. No te quejes de que
todas las críticas se te deberían haber enviado por
correo privado: así no es como funciona esto. Ni resulta
u´til insistir en que se te ha insultado personalmente
cuando alguien comenta que alguna de tus peticiones era
errónea (chapucear). E´ sas son actitudes de
perdedores.

Ha habido foros de hackers en los que, aparte de un
sentido de la hipercortesía mal guiado, se ha prohibido la
entrada a participantes por enviar cualquier mensaje haciendo
constar errores en los mensajes de los demás, y se les ha
dicho "No digas nada si no deseas ayudar al usuario". El
éxodo de los participantes más experimentados a
otros lugares les ha hecho descender al balbuceo sin el menor
sentido y han perdido toda su utilidad como foros
técnicos.

Exageradamente "amigable" (de esa manera) o
u´til: Elige uno.

Recuerda: cuando ese hacker te diga que te has
equivocado, y (no importa cuán rudamente) te diga que no
vuelvas a hacerlo, su actuación te concierne:

1. a ti y a

2. su comunidad.

Sería mucho más sencillo para él
ignorarte poniéndote un filtro. Si no eres capaz de ser
agradecido ten al menos un poco de dignidad, no te quejes y no
esperes que te traten como una frágil muñeca
sólo porque seas un recién llegado de alma
teatralmente hipersensible y con ilusiones de estar autorizado a
todo.

6. Preguntas que
no se deben hacer

NO HACER PREGUNTAS SUPERFLUAS

7. Si no logras
conseguir una respuesta

Somos conscientes que que hay mucha gente que
sólo quiere usar el software que escribimos y no
está interesada en conocer los detalles técnicos.
Para la mayoría de la gente, un computador es meramente
una herramienta, un medio para un fin. Sabemos eso y no esperamos
que todo el mundo se interese en asuntos técnicos. No
obstante, nuestro estilo de responder se encuentra orientado a
quienes sí se toman ese interés.

7 Acrónimo de "Preguntas de Uso
Frecuentes."

Por esto, si no obtienes respuesta, no te tomes como
algo personal que no sintamos que podamos ayudarte. Hay otros
recursos a menudo mejor adaptados a las necesidades de un
principiante.

Hay muchos grupos de usuarios en línea y locales
compuestos por entusiastas del software incluso aunque nunca
hayan escrito software alguno ellos mismos. Estos grupos se
forman de manera que la gente pueda ayudarse entre sí y
ayudar a los nuevos usuarios.

Hay además muchas compañías
comerciales a las que puedes contratar para que te presten su
ayu- da, tanto grande como pequeña. ¡Que no te
aterre la idea de tener que pagar por un poco de ayuda!
Después de todo, si al motor de tu carro se le rompe una
pieza seguramente tendrás que llevarlo al mecánico
y pagar para que te lo arreglen. Incluso aunque el software no te
costase nada, no puedes esperar que el soporte sea siempre
gratuito.

Para el software popular como Linux, hay al menos unos
10.000 usuarios por cada desarrollador. Resulta imposible que una
sola persona pueda atender llamadas de soporte técnico de
cerca de 10.000 usuarios. Recuerda que aunque tengas que pagar
por el soporte, estás au´n pagando mucho menos que
si tuvieses que comprar el software (y el soporte para el
software de código cerrado es por lo general mucho
más caro y menos competente que el soporte para el
software de código abierto).

Referencias

[1] @Crackberrista; Guía"Cómo
hacer preguntas inteligentes". Semanario "6to Poder", Cuerpo B,
Pág – 11.

[2] Raymond S; Eric Cómo hacer preguntas
inteligentes.

[3] Tatham Simon; Cómo informar de errores de
manera efectiva

Autor:

Eric S. Raymond

Iosu Landa Marcano

Enviado por:Horux Gungner

Cumaná, Edo.Sucre – Venezuela; 25 de
abril de 2011