¿Qué has intentado?

Esta es una traducción del artículo de Matt Gemmell, cuyo original se puede leer en http://whathaveyoutried.com

Si eres un desarrollador de software y estás a punto de preguntarle a otro desarrollador una pregunta técnica —en un foro, por correo, por un chat o en persona– debes de estar preparado para contestar a la pregunta “¿Qué has intentado?”.

Claro que esto no es específico para desarrolladores de software, pero es éste mi campo y por lo tanto, el área en la que me es muy familiar el problema que me motiva a escribir esto. Estoy (lamentablemente) muy seguro que aplica a tu propia industria también, cualquiera que ésta sea.

El asunto es, hay una enfermedad en la comunidad de desarrollo de software; una especie de malestar. Se trata de una enfermedad inusual, ya que muchas veces no es algo que se te pegue una vez que te unes a la industria (cómo lo son las canas, la adicción a la cafeína y una úlcera), sino algo que los nuevos reclutas ya tienen cuando comienzan.

Una pequeña clarificación antes de que continúe: cuándo me refiero a los “nuevos reclutas”, no sólo hablo de los recién graduados y otras personas jóvenes. Habrá aquellos que dirán que esta enfermedad es producto de los sistemas de educación occidentales modernos, y que las cosas tal vez han sido mejor en el pasado. Tal vez esto es cierto, y tal vez no —no tengo las credenciales para afirmar o negarlo, y de cualquier modo, no es la postura que estoy asumiendo. La enfermedad de la que hablo parece afectar tanto a los jóvenes como los adultos por igual.

La enfermedad, claro, es una manera errada de acercarse a la resolución de problemas. Acá les va un ejemplo, una cita textual de un foro en internet:

1) Podemos establecer una conexión http en la aplicación
entonces necesito ese codigo.
Vi NSURLConnection. No puedo integrar ese codigo.
2) Quiero mostrar una imagen de la página web
Alguien me puede dar el codigo?
Si alguien tiene un programa de ejemplo porfavor denmelo.

Entonces, ¿cual es el problema? No es la calidad de su español (es suficientemente evidente que el español no es su lengua materna, aunque esto no importa siempre y cuando las intenciones sean claras — y lo son). No es la puntuación ni la gramática, ya que estas no son particularmente importantes en este contexto, siempre y cuando no se vuelvan barreras para entender lo que se está preguntando.

El problema está en la técnica de resolución de problemas de este individuo: pedir la solución. No está buscando consejo sobre como acercarse al problema, o preguntando por los nombres de las clases que buscar, o un link a un ejemplo; No, solo pide el código, perfectamente formateado y listo para ejecutarse. Esto no es resolver problemas, y la ingeniería de software se trata completamente de resolver problemas.

Tenemos que notar algo interesante en el ejemplo anterior, éste no es tan malo como podría ser; se puede, a penas, ver la luz al final del túnel en la afirmación de que esta persona “vio NSURLConnection”. De ésto podemos tener algo de confianza, ya que NSURLConnection es, de hecho, una clase adecuada que aprender cuando quieremos hacer conexiones por HTTP en Cocoa. Sin embargo, parece que “ver” fue básicamente todo lo que hizo nuestro amigo en su esfuerzo. No pudo “integrar ese código” y por lo tanto, se rindió.

Este es un asunto que todos vemos constantemente (y no me refiero a tener problemas levantando conexiones por HTTP). Hay un grupo gigante de auto-denominados “desarrolladores” cuyo primer y último ángulo cuando se les pide resolver un problema, es simplemente preguntar cuál es la solución entera en otro lado, por lo general en foros u otros canales de ayuda adecuados. Su meta es la misma que la nuestra: tener código que resuelve el problema, que después pueda ser entregado al cliente. Dicha meta es razonable y perfectamente normal.

Lo que no es normal es la reticencia (Dudo hablar de “inhabilidad”, ya que, a fin de cuentas, sólo pocas cosas son realmente —fundamentalmente— difíciles si le echas suficientes ganas y coco) para alcanzar la meta mediante un proceso autodidacta, intentos francos y el proceso iterativo clásico de refinar y mejorar algo hasta que éste sea aceptable. El mismo proceso, a su vez, te prepara mejor para enfrentarte al próximo reto, y tarde o temprano encuentras que:

• Hay un grupo de problemas similares para los cuales ya tienes la respuesta, y puedes acercarte con confianza; y
• Eres más que capaz de enfrentarte a problemas nuevos generalizando lo que sabes actualmente y llevando a cabo un poco de investigación enfocada
• Éste no es un “truco” para la ingeniería de software, sino el mismo proceso de aprender como hacer cualquier cosa en la vida.

No es un secreto que sea impartido en las instituciones de educación superior, es simplemente la manera en que funcionan las cosas: empiezas con una falta de conocimiento sobre un tema, y una necesidad de resolver un problema del mismo. La manera honesta y sustentable de lograrlo es mejorando tu entendimiento, a través de:

1. Formular una pregunta, que, al ser contestada correctamente, mejore tu entendimiento de alguna manera; y depues
2. Intentar resolver el problema.

Nótese el segundo paso. Argumentar que recibir la solución completa de alguna manera satisface este proceso es ser flojo y deshonesto, y probablemente termine por no hacerte merecedor de ayuda. Ya que, después de todo, ¿por qué habría de hacer tu trabajo alguien más?

He tenido muchas experiencias personales con personas que demuestran esta preocupante reticencia a aprender, investigar, o intentar. He liberado mucho código al pasar de los años, y me he vuelto muy visible en la comunidad del software libre debido a las plataformas en las que trabajo. Los colaboradores de software libre a veces son vistos como maestros freelance — esto implica que recibo muchos correos en dónde me solicitan ayuda con una cosa u otra, y los ayudo en la medida de mis posibilidades.

He ayudado a —literalmente— a cientos de personas que comienzan a programar con Cocoa, desde el lanzamiento inicial de Mac OS X. No envío respuestas automatizadas, sino que contesto a cada correo de manera personal e individual. Desde problemas específicos con código (de manera inclusiva, más no limitativa, preguntas sobre mi propio código), recomendaciones de libros, hasta consejos sobre como empezar a programar en si. He cumplido con mi responsabilidad en este sentido, porque realmente creo que [ayudar] es nuestra responsabilidad.

Sin embargo, esto es la vida real, y ningún principio ético se puede evaluar fuera del contexto de la realidad. La ayuda podrá ser gratuita en su mayor parte, pero esto no significa que proporción entre el costo y beneficio no deba ser considerada. Mi beneficio al hacerlo puede emanar de hacerme sentir bien, en vez de una recompensa monetaria, pero si me estás haciendo perder el tiempo, entonces no te veré tan merecedor como quien realmente quiere aprender.

He aquí el secreto: la disposición y deseo de aprender, son las verdaderas credenciales.

No es la habilidad; todos tenemos diferentes niveles –innatos y desarrollados– de capacidad para aprender ciertas habilidades. Algunos, probablemente la mayoría, de los cuales pueden ser mejorados con la práctica, mientras que otros no. Está mal generalizar la habilidad de una persona en una disciplina entera, sólo por sus aparentes dificultades en un aspecto particular de dicha disciplina. Si quieres que alguien invierta tiempo y esfuerzo (especialmente, si es tiempo que están regalando), entonces más vale que te lo ganes.

Ganarlo no se trata de aventarle algunos billetes a tu tutor, ni siquiera se trata de exitosamente completar tu tarea: se trata de intentarlo, carajo. Los desarrolladores de los que hablo parecen, increíblemente, indispuestos a intentarlo. Por supuesto, muchos de nosotros los ignoramos. Problema resulto, ¿cierto? Falso.

Se desencadena un inmenso efecto negativo cuando la norma es esta falta de disposición a hacer el esfuerzo de resolver los problemas por tus propios medios. La gente que está en una posición para ayudar, deja de frecuentar las salas de chat, foros y listas de correo. “Mucho ruido y pocas nueces”, dicen, con algo de razón. Los que salen perdiendo son las desarrolladores genuinos (por lo que me refiero a la gente bien intencionada, con ganas de aprender, que suceden ser nuevos a un área en particular) que naturalmente eligen estos lugares para hacer sus preguntas. Estas personas, entonces, tienen una probabilidad reducida de obtener orientación significativa, ya que implica un gran esfuerzo determinar quién es un huevón y quién no.

Esto último es una situación horrible, y nunca ha sido más relevante que ahora; las plataformas jóvenes o recientemente populares, están expuestas a este fenómeno más que la mayoría de las plataformas. Hay menos gente con verdadera experiencia, el nivel promedio de experiencia es menor, y la cantidad de ayudar solicitada es mayor; por lo tanto, hay una proporción más grande de huevones en la mezcla. Esto es lo que sucede con el iPhone, Android, y demás.

Así que, si vas a hacer una pregunta técnica, supongo que la primer cosa que te debería de decir es: “¡Bien! Estás haciendo una pregunta, y por esto asumo que hay una mejor posibilidad de quie quieras aprenderá algo. Esto es —normalmente— increíble, y estoy listo para saludarte” N. del T.: en el sentido de “La porra te saluda”

Aguántala. ¿Haz pensado, realmente pensado, qué es lo que estás por preguntar? ¿Es este el momento correcto para preguntar, o puedes tomar un paso más antes de hacerlo, si éste hará tu pregunta más clara (buena) o probablemente innecesaria (mejor)?

Intenta tomarte algunos minutos para revisar esta lista:

• ¿Haz dividido tu problema en partes suficientemente pequeñas para hacer una pregunta concreta? En el campo de la ingeniería de software puedes dividir, casi cualquier problema, en dos categorías: 1) problemas que se pueden dividir en problemas más pequeños, y 2) problemas que ya sabes resolver o que son triviales de investigar.
• ¿Tu problema es como una pregunta estándar, para la cual hay sin lugar a dudas una implementación de referencia y documentación disponible? No hay SDK para interfaces gráficas que no tenga una sección a manera de tutorial en la que se explique como colocar una ventana en pantalla. No existe lenguaje de programación que no te diga como leer los contenidos de un archivo. Hojea la documentación, o haz una búsqueda rápida. Si tu problema es tan sencillo de resolver, la respuesta probablemente se encuentre a la vuelta de la esquina, encuéntrala!
• Intenta buscar en internet. Esto parece un consejo redundante, lo sé, sólo continua leyendo. Si estás teniendo problemas encontrando un resultado decente, entonces necesitas acotar tu búsqueda. No busques “instrucción condicional N del T.: if statement”, si solo estás interesado en una instrucción condicional de ruby; mejor busca “ruby instrucción condicional”. Sería aún mejor encontrar una página específica al lenguaje o tecnología con la que estás trabajando, y buscar en el mismo. Para Cocoa, esta es el archivo de la lista de correos de CocoaBuilder. Probablemente alguien más —tal vez cientos de personas— han hecho la misma pregunta ya.
• Quien haya escrito el lenguaje, framework, API o lo que sea, seguramente creo una bola de código de ejemplos; te lo prometo, lo hicieron. Están hechos con la finalidad de ayudarte a resolver varias tareas comunes, y probablemente hayan cubierto alguna parte de tu caso en particular. Sólo te tomará algunos minutos revisarlo, y por lo menos, encontrarás mucho código que te será probablemente útil en el futuro.
• Usa las referencias en línea o documentación emebebida de tu IDE. Xcode tiene un navegador de documentación. Eclipse y similares te pueden mostrar la documentación de clases de Java. PHP.net es tu recurso de elección para escribir PHP. Encuentra la referencia canónica para tu herramienta, y busca en ella. Vas a encontrar algo de ayuda casi siempre.

Muy bien, ya que has leído estos pasos, y has intentado algunos de ellos, entonces te puedo felicitar. Ya sea que tú resolviste tu problema (lo cual es genial), o ya estás listo —oficialmente — para recibir ayuda.

Cuándo te pregunto “¿Qué has intentado?”, puedes decir con toda confianza que has intentado todo lo que menciono arriba, y me podrás contar sobre todas las posibles soluciones que encontraste, o que honestamente, no encontraste. Te voy a ayudar entonces, porque puedo ver que quieres aprender y que estás dispuesto a echarle los kilos; no sólo voy a ayudarte, voy a querer hacerlo.

Ésta es la conclusión clave. Cuándo te pregunten “¿Qué has intentado?”, no significa “muéstrame el código que has escrito o lárgate”. Lo que tienes que hacer es, de perdida, intentar ayudarte a ti mismo: intentar es lo importante.

No sólo para evitar joder a alguien que, de otro modo, está dispuesto a dar gratuitamente su valioso tiempo para ayudarte, sino para tu propio crecimiento personal. Lleva a cabo este método suficientes veces y la cantidad de problemas para los que necesitarás hacer preguntas disminuirá. Además, te encontrarás en la posición de ayudar a los demás (incluyéndome), y de este modo todos ganamos.

Así que la próxima vez que estés considerando hacer una pregunta, más vale que estés listo para responder de manera convincente la pregunta “¿qué has intentado?”.

Si tu respuesta suma a “no mucho”, créeme, la siguiente pregunta que te harán será “Entonces, ¿por qué habría de ayudarte?”.