Si sos un desarrollador y estás por hacerle una pregunta técnica a otro desarrollador (ya sea en un foro, mail, chat o en persona), mejor que estés listo para contestar la pregunta “¿Qué intentaste?”.
Por supuesto, esto no es exclusivo del desarrollo de software, pero esa es mi área, y es la que me motivó a escribir eso por ser con la que más familiarizado estoy. Estoy (lamentablemente) seguro de que aplica a tu industria, también, sea la que sea.
El tema es que hay un mal en el mundo del desarrollo de software, una especie de enfermedad. Es una enfermedad extraña, porque no es algo que te agarrás cuando entrás a la industria (como las canas, la adicción a la cafeína o la úlcera), sino algo que los nuevos ya traen consigo cuando entran.
Antes de seguir, una rápida aclaración: cuando digo “los nuevos”, no me refiero sólo a los recién graduados y gente jóven. Hay quienes dirán que esta enfermedad es producto de los modernos sistemas de educación occidentales, y que las cosas solían ser mejor antes. Puede que eso sea cierto, como puede que no; no me siento calificado para determinarlo, y ese no es el punto que quiero exponer. La enfermedad de la que hablo parece aplicar a jóvenes y veteranos por igual.
La enfermedad, por supuesto, es el pésimo enfoque en la resolución de problemas. Este es un ejemplo real extraído de un foro en internet:
1) Puedo yo establecer conexión http en una aplicación.
si puedo, necesito el código.
Miré NSURLconnection. No puedo integrar ese código.
2) Quiero mostrar una imagen en el sitio web.
¿Alguien es tan amable de darme el código?
Si alguien tiene un ejemplo simple por favor démelo.
Entonces, ¿dónde está el problema? No está en el uso del idioma (es bastante evidente que esta persona no habla español nativamente, y eso no importa mientras la intención esté clara – que lo está). No está en la puntuación ni la gramática, porque esas cosas tampoco son particularmente importante en este contexto mientras no se conviertan en barreras para entender la pregunta.
El problema es que la táctica para resolver problemas de esta persona es pedir la solución. No es pedir consejos sobre cómo encarar la tarea, ni preguntar el nombre de las clases en las que debería empezar a buscar, ni un link a un ejemplo: simplemente pedir el código, completo y funcional. Esto no es resolver problemas, y la ingeniería de software ES resolver problemas.
Es interesante notar que el ejemplo de arriba no es tan pésimo como podría serlo: hay un dejo de iluminación en eso de que “Miré NSURLconnection”. Esa frase inspira un poquito de confianza, dado que NSURLConnection es efectivamente una clase que hay que conocer para hacer conexiones HTTP en Cocoa. Aún así, parece ser que “mirar” es el esfuerzo máximo de nuestro amigo: no pudo integrar el código, por lo que se rindió.
Este problema lo vemos constantemente (y no me refiero a problemas al hacer conexiones HTTP). Existe una clase de “desarrolladores” cuya primer y única estrategia de resolución de problemas es simplemente pedir una solución completa en algún lado, generalmente en foros u otros canales de ayuda apropiados. Su objetivo es el mismo que el nuestro: tener código que resuelva el problema, que sea susceptible de enviarse al cliente. Ese objetivo es razonable, y bastante natural.
Lo que no es natural es la falta de voluntad (no se si llamarla incapacidad, dado que, después de todo, muy pocas cosas son realmente dificiles si aplicás el esfuerzo y cabeza suficientes) para cumplir ese objetivo mediante un proceso de auto-educación, reales intentos y el proceso iterativo clásico de refinar y mejorar hasta crear algo aceptable. Este proceso, a su vez, te deja mejor preparado para enfrentar el próximo desafío, y tarde o temprano descubrís que:
- hay grupos enteros de problemas conocidos para los que ya sabés la respuesta y los podés resolver con confianza; y
- sos capaz de encarar problemas desconocidos generalizando tus conocmientos actuales y efectuando una pequeña investigación enfocada.
Esto no es ningún truco de la ingeniería de software: este es el proceso para aprender cualquier cosa.
No es un secreto propio de las instituciones de educación avanzada, simplemente es como funcionan las cosas: empezás desconociendo partes de un tema, y teés que resolve run problema relacionado con él. La forma honesta y sostenible de lograrlo es mejorar tu entendimiento. Para esto:
- Te formulás una pregunta que, cuando encuentres la respuesta, mejore tu entendimiento en mayor o menor medida; y
- Tratás de responderla.
Hay que notar el segundo paso de esto. Decir que conseguir la solución completa por arte de magica satisface este proceso es ser vago y deshonesto, y probablemente te hace una persona que no merece ser ayudada. Después de todo, ¿por qué habría alguien de hacer tu trabajo por vos?
Vi montones de casos de gente con esta molesta falta de volutad de aprender o investigar o probar. Liberé montones de código a lo largo de los años, y soy bastante visible en la comunidad open source por las plataformas con las que trabajo. Como parece que los contribuidores open source son vistos como profesores freelance, eso significa que recibo montones de mails pidiendo ayuda con una cosa u otra. Y trato de ayudar cada vez que puedo.
Desde el lanzamiento de Mac OS X ayudé literalmente a cientos de personas que querían arrancar con Cocoa. No mando respuestas preparadas, tampoco: contesté cada mail individualmente. Desde problemas específicos de código (incluidas, pero para nada limitadas a, preguntas sobre mi propio código) y recomendaciones de libros, hasta consejos sobre cómo iniciarse en la programación en general; cumplí con mi deber en ese asunto, y realmente creo que es un deber. La gente con capacidad de hacerlo en cualquier medida debería ayudar a quienes a su vez pueden ser capaces de hacer lo mismo. Seguramente esa sea una verdad fundamental, además del deseo de todos nosotros.
Pero eso es la vida real, y ningún principio está exento de ciertas consideraciones de la realidad. La ayuda puede ser principalmente gratis, pero eso no significa que no haya una relación costo-beneficio que considerar. Mi beneficio puede ser una leve sensación de calorcito en el pecho en vez del vil dinero, pero si me hacés sentir que desperdicio mi tiempo va a valer más la pena ayudar a alguien que realmente quiera aprender.
Éste es el secreto: la voluntad y las ganas de aprender son las verdaderas aptitudes.
No dije habilidad: todos tenemos distintos niveles de habilidad (natos y adquiridos) para adquirir ciertos conocimientos o técnicas. Algunos (probablemente la mayoría) pueden mejorarse con la práctica, y otros no (y es un error generalizar a la habilidad de alguien en una disciplina las dificultades que tiene sólo en algún aspecto de la misma). Pero si vas a involucrar el tiempo y esfuerzo de otra persona para resolver algo, más vale que te lo ganes (y más aún si lo hace gratis).
Ganárselo no se trata de tirarle un par de unidades de alguna moneda a quien te enseñe, ni significa resolver adecuadamente tu problema: se trata de intentarlo a fondo. E intentarlo es justamente lo que esta raza de desarrolladores de la que hablo extrañamente no tiene ganas de hacer. Entonces, obviamente, muchos de nosotros los ignoramos. Fin del problema, ¿no? No.
Existe un devastador efecto negativo causado por la proliferación de esta falta de voluntad de resolver sus problemas uno mismo: quienes están en condiciones de ayudar dejan de frecuentar los foros, listas de correo y salas de chat. “Demasiado ruido”, dicen, con algo de razón. Los que pierden son los verdaderos (me refiero a los que realmente tienen la voluntad de aprender, sólo que recién están empezando con algún tema en particular) desarrolladores que naturalmente eligen esos lugares para resolver sus genuinas dudas. Esos ven reducidas sus chances de conseguir ayuda significante, debido al esfuerzo que implica distinguir a quienes merecen el esfuerzo de quienes no.
Esto es desastroso, y pocas veces fue tan crucial, dado que, lógicamente, las plataformas más nuevas o que tienen gran auge son las que más sufren este fenómeno. La gente realmente experta es poca, el nivel de experiencia promedio es menor, la ayuda requerida suele ser más, y es mucho mayor la proporción de haraganes a la que sólo le interesa cobrar. iPhone y Android son dos tecnologías que ejemplifican esto.
Así que, así vas a hacer una pregunta técnica, lo primero que tengo para decirte es: ¡Genial! Estas haciendo una pregunta, así que hay grandes chancees de que estés queriendo aprender algo. Eso suele ser genial, y me preparo para felicitarte por ello.
Pero, un momento: ¿Pensaste bien (realmente bien) qué es lo qué vas a preguntar? ¿Es buen momento para preguntar, o hay todavía algún paso previo qué puedas dar para hacer que tu pregunta sea más clara (¡bien!) o innecesaria (¡mejor aún!)?
Tomarte unos minutos y pensá en lo siguiente:
- ¿Acotaste el problema o la pregunta lo suficiente como para estar preguntando algo concreto? En ingeniería de software, la mayoría de los problemas pueden dividirse en dos categorías: (1) cosas que podés seguir dividiendo y acotando; y (2) cosas que ya sabés hacer o que podés buscar fácilmente.
- ¿Es tu pregunta lo suficientemente estándar como para que seguramente tenga que haber ejemplos y documentación disponible? No existe en el mundo un framework para hacer interfaces gráficas que no tenga en sí documentación un ejemplo para crear una ventana en la pantalla. No hay lenguaje de programación que no explique como leer el contenido de un archivo. Ojeá la documentación, o hacé una búsqueda rápida. Si tu duda es así de simple, la respuesta seguramente esté al alcance de la mano. ¡Busque, busque!
- Buscá en internet. Parece un consejo tonto, pero buscá en internet. Si te está costando conseguir resultados útiles, acotá la búsqueda. No busques “instrucción if” si solo estás buscando el if de Ruby: buscá “instrucción if ruby”. Mejor aún puede ser encontrar un sitio específico de la tecnología que te interesa, y buscar ahí. En el caso de Cocoa, sería la lista de mensajes de CocoaBuilder. Probablemente ya alguien haya hecho tu misma pregunta (¡o incluso cientos de alguienes!).
- Quien sea que haya hecho tu framework, API o lo que sea, también tuvo que haber hecho códigos de ejemplo. En serio, seguro que lo hicieron. Lo diseñaron para que te ayude a iniciarte con cuestiones comunes, y puede que haya código que resuelva al menos una parte de lo que querés hacer. Te lleva unos pocos minutos fijarte, y, en el peor de los casos, al menos conseguiste un montón de ejemplos para tener a mano a futuro.
- Usá la ayuda online de tu IDE. XCode tiene un navegador de la documentación. Eclipse y otros te muestran el javadoc de las clases. PHP.net te cubre con tus scripts PHP. Encontrá la referencia primaria de lo que estés usando, y buscá ahí. La mayoría de las veces vas a encontrar algo útil ahí.
OK, entonces ya revisaste estos pasos e intentaste varios de ellos. Ahora sí puedo decirlo: felicitaciones, tu problema ya está resuelto, o ya estas oficialmente listo para ser ayudado.
Cuando te pregunte “¿Qué intentaste?”, podrás decirme con confianza que intentaste todo esto, y me vas a poder decir todas las cosas útiles que averiguaste mientras buscabas, o al menos vas a poder decirme que realmente no encontraste nada. A esta altura, voy a ayudarte, porque puedo ver que querés aprender, y que tenés voluntad de esforzarte para lograrlo, por lo que voy a querer enseñarte.
Esa es la clave que hay que entender. Cuando te preguntan “¿Qué intentaste?” no te están diciendo “muéstrame tu código o púdrete”. Lo mínimo que tenés que hacer es tratar de ayudarte a vos mismo (y lo de “tratar” es lo realmente importante).
No es solo para no enfurecer a alguien que de otro modo te habría podido ayudar, sino para tu propio crecimiento personal. Hacelo las veces suficientes, y vas a ver como empieza a bajar la cantidad de veces que realmente necesites preguntar. Además, vas a empezar a estar en posición de ayudar a otros (incluyéndome), así que ¡todos ganamos!
Así que la próxima vez que estés pensando en hacer una pregunta, mejor que tengas una buena respuesta a “¿Qué intentaste?”.
Si tu respuesta se acerca a “no mucho”, créeme: la próxima pregunta que te hagan va a ser “¿Por que habría de ayudarte, entonces?”
Cualquier comentario sobre el artículo o la traducción es bienvenido.
Matias Garcia Isaia 