Ayuda, lo necesito urgente!

Una vez más vengo a atacar (solo un poquito) a los usuarios, esos que a veces defiendo tanto. No quiero generalizar, así que al que no le toca que no le toque. Tampoco es que yo tenga un trastorno bipolar, doble personalidad o alguna de esas condiciones psicológicas que no se exactamente qué significan. Lo que pasa es que valoro mucho y trato de fomentar la contribución de muchos buenos usuarios por un lado, pero también a veces me sacan de quicio los mensajes de otros por el otro. En el fondo, puede que todo sea mi culpa, así que vamos a tratar de hacer una crítica constructiva de ambos extremos de la comunicación (va con un poco de humor para no enojar a nadie).

La gente escribe (por mail, por formularios en el sitio web, por los foros, por el chat, da igual) preguntando/diciendo cosas de PSeInt, ZinjaI, C++, programación, o cualquier cosa que les parezca. Muchos mensajes son útiles, muchos habría que ignorarlos, otros no lo se porque ni siquiera los entiendo. Hay problemas en dos niveles: qué quieren decir, y cómo lo dicen. Empecemos por el primero, más básico, elemental, aplicable a cualquier comunicación escrita en cualquier ámbito. Para que entiendan bien todos (especialmente los que lo hacen), lo voy a tratar de poner su lenguaje:
 * PARA EMPEZAR NO GRITEN.
 * Ezkrivan vien x fabor q no kuezta muchio.
 * No den ordenes ni exijan respuesta inmediata nunca jamás!
 * Aprendan comunicar al español con otros persona antes que quiere comunicar la máquina para C++.
 * Usen una coma un punto seguido dos puntos algo los signos de puntuación no muerden ayudan a entender mejor las oraciones gracias
 * Sean amables, soperútanos.

Habiendo dejado claras las falencias del lenguaje (que tal vez sean las que más me sacan), pasemos al contenido del mensaje. La primer súplica es: lean/busquen aunque sea un poquito (ayuda, foros, noticias, ejemplos, google, hay mil formas) antes de preguntar así porque sí. Y no copien y peguen el enunciado del problema 3 de la clase del lunes (o peor aún, toda la guía) bajo el asunto "ayuda! lo necesito urgente!". A uno (cualquiera, desarrollador o usuario amigo) no le da ganas de donar su tiempo a alguien que no hizo ni un mínimo de esfuerzo ni por escribir como se debe. Todos hemos necesitado ayuda muchas veces. Si lo intentaron resolver y se trabaron en algún punto, está bueno que expliquen en prolijo español qué pudieron hacer y qué es lo que no les salió, donde y por qué se trabaron. Entonces quienes lo lean tendrán una mejor predisposición para responder. No pierdan de vista que no están pagando directamente por este servicio. A muchos usuarios piolas les satisface ayudar, contribuir a la comunidad, o simplemente mostrar que saben, pero no abusen de ellos o cuando de verdad necesiten algo difícil ya no van a estar. Si realmente no tienen ni idea de cómo buscar o cómo preguntar, tal vez el problema no es ese problema, sino uno más básico, y puede que estén queriendo quemar etapas.

Pero ojo, que puede ser culpa mía. Tomemos un ejemplo clásico: "ayuda! no puedo instalar PSeInt". Acá hay dos deducciones de mi parte: o bien no leyó ni dos lineas, o bien no sabe preguntar. Las dos cosas son frecuentes. Para lo primero: es obvio que instalar el programa para empezar a usarlo es una tarea bien básica y frecuente, así que usando un poquito el sentido común, esa respuesta tiene que estar en algún lado, no sos el primero que lo quiere instalar. Y resulta que está nada menos que en la página de descargas, abajo de los enlaces, separados claramente por sistema operativo. Entonces, primer punto: ya lo dije, lean. Supongamos el segundo caso: que leyeron y algo salió mal. ¿Qué??? Si me preguntan "¿cómo instalo PSeInt?" les voy a repetir lo mismo que dice el sitio, ya que para eso lo dice. Si algo no fue por la vía normal, necesito saber qué, no tengo una bola de cristal, ni la Espada del Augurio. Entonces, ¿no lo pueden bajar? ¿se cuelga el instalador? ¿da un error al arrancar? ¿cuál? ¿cómo? ¿dónde? ¿qué??? Es muy probable que yo no haya tenido ese problema, así que la segunda súplica es: cuéntenme con el mayor detalle posibles los pasos que tengo que seguir para verlo, y adjunten capturas/ejemplos si pueden. Además, detallen el contexto, sepan que no sé ni qué versión del software, ni qué sistema operativo tienen, ni qué color de sombrero usan. No puedo analizar un bug si no lo veo, y para verlo necesito los detalles.

Pero aquí entonces, este segundo escenario se puede volver a desdoblar en dos opciones: o bien ustedes tienen un sistema muy raro que resulta un caso particular o rebuscado y de verdad necesitan ayuda específica, o bien las instrucciones del sitio no son claras, no están actualizadas, no están completas, o son horribles por el motivo que sea. Un tercer caso (pero de conclusiones asimilables al primero) podría ser que el programa tenga un bug importante. Entonces, como decía al principio del párrafo anterior, una posibilidad bastante factible es que sea culpa mía por no poner instrucciones claras o completas, o por dejar pasar un bug. Pero aún así necesito que pregunten mejor, explicando con detalle el problema para que me dé cuenta cual es la situación y vea cómo mejorar esas indicaciones o corregir ese bug.

Hay una sigla muy común en el mundo del software que se usa mucho para responder a los usuarios y es RTFM (Read The Fucking Manual = leé el Maldito Manual). A veces de verdad que se lo merecen, pero otras no. Mirando algunas presentaciones muy recomendables de Rich Bowen, encontré una respuesta (para nosotros los desarrolladores) que me pareción genial y exclarecedora: "si querés que tus usuarios lean el Maldito Manual, mejorá el Maldito Manual". No hay mucho más que agregar, claro como el agua. Es común en un proyecto chico que el programador también escriba el manual de su aplicación. Y el punto de vista del programador no tiene casi nada en común con el del usuario (y además ser bueno programando no implica ser bueno explicando). Y entonces el Maldito Manual puede resultar horrible y prácticamente inútil. Es bueno que nos hagan notar esas cosas y nos ayuden a mejorarlas. Sus preguntas, si están bien formuladas, son un muy buen indicador de dónde hace falta mejorar.

Por último queda la cuestión de dónde preguntar, que mezcla un poco de todo lo otro, pero en menor medida. Antes de preguntar hay que elegir dónde hacerlo, y aquí suelo ver otros errores, aunque no son graves ni mucho menos, pero todo suma para que la comunicación sea fluida. Uno de los dos errores más comunes en este sentido es preguntar por programación/C/C++, o usar el foro equivocado. ZinjaI se usa para enseñar a programar, pero para eso lo usa el docente en su cátedra. El sitio de ZinjaI es para información sobre el software, pregunten sobre ZinjaI, pero para preguntar sobre programación y C++ en general, como alumno, usen los medios que les brinde su profesor u otros sitios más conocidos que hay para eso. En PSeInt hice una excepción y abrí un foro para este tipo de preguntas, porque el de PSeInt es un lenguaje muy particular, y tal vez no tenga lugar propio en otros sitios. Por otro lado, lo que sucede con ese foro es que en general leo las preguntas pero no las respondo. No respondo porque el poco tiempo que tengo se lo dedico a los otros foros, los que sí me atañen exclusivamente. Las preguntas de pseudocódigo y programación en general se las pueden responder los usuarios entre ellos mismos (la idea de abrir ese foro era que se genere un diálogo entre usuarios para que los usuarios que van avanzando puedan ayudar respondiendo a los nuevos las cosas que yo no llego a responder, e intercambien material). Pero casi siempre leo igual lo que escriben para ver que no respondan cosas muy descolgadas, y para estar atento si preguntan por algún error que no es del usuario, sino del intérprete.

Supongamos ahora que la pregunta es pertinente, si escriben sobre el software, aún así tienen que tomarse un segundo para elegir el foro adecuado. No es lo mismo un reporte de error que una sugerencia por ejemplo. Digamos que en general yo debería priorizar corregir los errores antes que agregar nuevos detalles (aunque no siempre pasa :), y debería priorizar también los errores por su gravedad, y por eso también es útil que cada error tenga un hilo propio (o al menos los que parezcan más importantes). De esta forma es más fácil para todos buscar o hacer el seguimiento de cada problema. En muchos proyectos serios se usa algún sistema más formal tanto de reporte errores como de peticiones de nuevas funcionalidades (sourceforge ofrece este servicio en forma de tickets), pero yo preferí evitarlo porque obliga al usuario a seguir ciertos "formalismos". A veces esos pasos (aunque son mínimos), ya sea por tediosos, o por no ser tan claros al principio, hacen que el usuario desista de reportar el error/la sugerencia. En cambio, en un foro donde puede escribir libre y anónimamente con no más de dos clicks, casi no tiene excusa para no hacerlo. Solo que me obliga a depender más de su criterio y sentido común para obtener un reporte útil. Y a veces su criterio es realmente asombroso (aún en gente que se supone muy formada, no solo en alumnos de primero).

Debiera decir "common" en lugar de "best". No es la mejor

 práctica, pero es lo que pasa en muchos casos.

Espero no ofender a nadie si se siente identificado con las cosas que critico. Tampoco quiero encasillar a los usuarios en el grupo de los que realmente me ayudan y el grupo de los que me sacan. Un mismo usuario puede cambiar de grupo aún dentro de un mismo mensaje, así que hay grises. Además, ya dije que también hay buena parte de culpa mía por falta de paciencia, por errores involuntarios, o por no ofrecer una documentación más decente. La idea es que entre todos nos entendamos para que estos problemas de comunicación se solucionen y podamos sacarle más provecho tanto a los programas como a los foros.