El siguiente texto es una traducción [un tanto libre] del capítulo Human Driven Development,  del libro Conscious Software Development de Jeff McKenna.

Lo relacionado con el software es hard

Si usted es un desarrollador joven, es probable que acostumbre trabajar solo en un computador. Tal vez disfrute resolviendo problemas por su cuenta. Muchos de nosotros en el negocio del software iniciamos nuestras carreras trabajando aislados y nos gusta.

Pero si vamos a resolver problemas en un contexto comercial, entonces tendremos que aprender a disfrutar trabajar con otros.

Los sistemas complejos como el software solo pueden ser diseñados y desarrollados por varias personas trabajando juntas para resolver problemas, obligándolas a comunicarse entre ellas – no solo con el computador. Este es un mensaje importante del desarrollo de software ágil que dice: “Podemos hacer más si trabajamos como un equipo.”

¿Pero qué significa esto para usted como individuo? ¿Significa que tiene que cambiar su forma de ser? ¿Que ahora usted debe actuar diferente? ¡Es probable que así sea!

¿Significa que usted tiene que aprender de una forma diferente? Nuevamente la respuesta es: ¡Es probable que así sea!

¿Cómo puede lograr esto? Siendo consciente sobre la forma en que usted trabaja, pensando acerca de sus procesos y los procesos de su equipo de trabajo – y no solo sobre los procesos del computador.

Muy temprano en mi carrera profesional, el computador era la pieza central. Nada mejor que ir solamente por el problema y resolverlo.

Como desarrolladores, estamos inclinados de forma natural a hacer cualquier cosa por nuestra cuenta. Sentados frente a la máquina, encendemos nuestro sistema, tecleamos el trabajo y lo enviamos. Las primeras manifestaciones de problemas aparecen cuando alguien lee la documentación o el código y encuentra errores simples, cosas como palabras que hacen falta o excepciones ausentes.

Si los errores tipográficos y los fallos en la codificación fueran el único efecto dañino de trabajar en solitario, no sería un gran problema. Pero trabajando junto a otras personas es algo que está más allá de simples errores de omisión. El punto más crítico es que cuando trabajamos solos perdemos la oportunidad de ayudarnos unos a otros y de mejorar en lo que hacemos.

Buscando un contrato de consultoría, envié una de mis primeras propuestas a un gerente de proyectos de software quien le dio una ojeada y me hizo tres preguntas. Respondí las dos primeras sin problemas, pero fallé en la tercera – había pasado por alto un defecto de diseño muy simple y, en un abrir y cerrar de ojos, se terminó. No conseguí el contrato.

Ese momento fue un despertar para mí. Aprendí que el hecho de trabajar en algo y creer que se hizo bien no significa que esté bien hecho. Aprendí que necesitaba ayuda, y no solo cuando aparece un problema, sino durante todo el camino. Cuando usted va solo, puede cometer los errores más tontos.

Fue el primer indicio que tuve al respecto. “Un momento, esto de ser Llanero Solitario no va a funcionar.”

Aprendiendo a aprender

Así que ahora aparecen las preguntas, ¿Cómo aprendo cómo aprender en este nuevo mundo? Para resolverlo, tengo que entender cómo aprendo yo. Esto aplica para usted – usted tiene que entender cómo aprende.

¿Lee libros?

¿Habla con otras personas?

¿Primero debe intentarlo en la práctica y luego lee sobre el tema?

¿Qué funciona para usted? ¿Qué se le dificulta?

Lo difícil está bien, si esto es efectivo. Lo fácil también está bien.

Yo se que aprendo mejor leyendo. Si necesito aprender un nuevo lenguaje, comienzo leyendo el manual completo y luego resuelvo algunos problemas usando el lenguaje. He aprendido que si solo me sumerjo en resolver problemas con una nueva tecnología sin un panorama; sin una imagen global, como la que se obtiene leyendo primero un manual, me costará mucho.

Esto lo aprendí probando los dos métodos. Identifiqué mi mejor modo de aprender a través de ensayo y error. El suyo es diferente al mio. ¿Cuál es?

Los académicos y los teóricos pueden decirle un montón de cosas sobre la forma en que las personas aprenden, y si usted está interesado en el estudio del aprendizaje, entonces no lo dude y estúdielo. Pero al final lo que importa es comprender cómo aprende usted y la única forma de hacerlo es ensayar métodos y después mirar de manera honesta los resultados.

Además de leer, me gusta aprender interactuando con otras personas, por esta razón programar en parejas es una práctica maravillosa para mi, no solo porque se elabora mejor código, sino porque se aprende muchísimo.

Analice como aprendió las cosas que conoce mejor

¿Cómo aprendió, por ejemplo, a juzgar si un diseño es bueno o malo? Si usted es precipitado, su repuesta podría ser, “¡Pues, hermanito, solo lo codifico y si funciona, entonces para mí es un buen diseño!

Bien, eso no será suficiente hoy en día. Usted necesita tener un proceso establecido que le permita explorar ideas alternativas antes de comenzar a codificar.

Yo necesito imágenes cuando hablo sobre diseño; las palabras no son suficientes. Sin imágenes, se que no puedo saber realmente cuál es el diseño. Me tomó mucho tiempo darme cuenta que esto me ocurría. Construí una de las primeras herramientas de modelamiento gráfico sin haber hecho algún modelamiento -pues yo no conocía algo mejor. Irónico ¿cierto?

Luego conseguí un trabajo en otro lugar utilizando esta misma herramienta de modelamiento para hablar sobre diseño. La compañía que me contrató deseaba explorar a profundidad el problema de diseño que estábamos enfrentando, y utilizamos la herramienta para hacerlo.

El bombillo se encendió para mi. Me di cuenta de la cantidad de formas en que se puede hablar de un problema usando algún tipo de lenguaje gráfico. Logré adquirir la habilidad de mirar las cosas de forma diferente y comunicarme con diferentes personas para hablar sobre el tema.

Así que tómese un tiempo, reflexione sobre sí mismo, busque las cosas que le ayudan a aprender mejor y, entonces, haga más de eso. Usted puede encontrar el tiempo, porque escribir código en la actualidad no consume tanto tiempo como antes. Si usted puede tener su base de conocimiento creciendo por delante de otros en su campo, usted se mantendrá haciendo las cosas mejor y mejor.

El panorama general es  el detalle, el detalle es el panorama general

“¿En qué estoy interesado?”

Esa es la pregunta realmente importante.

El desarrollo de software con consciencia  implica mantenerse actualizado consigo mismo, con la tecnología y con su equipo de trabajo.  Esto implica mostrarse y estar disponible a todas las personas y actividades que están alrededor suyo. Por esta razón cuando hablo sobre “aprendizaje” en el contexto del desarrollo de software, no solo estoy hablando de las destrezas técnicas, hablo del aprendizaje que está ocurriendo a su alrededor en este momento, y del aprendizaje que viene y que debe apropiarse.

Uno de mis primeros trabajos en programación fue en Australia en la década de 1960, trabajando para una organización grande dedicada a la investigación. Su cultura exigía que toda persona en la compañía debía dedicar al menos cuatro horas a la semana para aprender cosas nuevas.

Ellos no querían que nosotros nos enfocáramos en aprendizaje incremental: aprender cómo hacer alguna cosa nueva con la tecnología que ya conocíamos y usábamos; ellos deseaban que miráramos más lejos. Así que dedicábamos ese tiempo a aprender y luego reportábamos sobre lo que habíamos aprendido.

Aprender no es sólo sobre mejorar las destrezas y el uso de las herramientas que usted está usando actualmente. No es solo sobre cosas como estas: ¿Cómo puedo ser un mejor programador en Java? Es importante que usted no dedique todo su tiempo a los detalles de su profesión, pues no tendrá tiempo para ver las cosas importantes que vienen hacia usted -y las cosas importantes vienen a usted todo el tiempo.

Las pequeñas cosas es mejor aprenderlas haciendo. Haciendo el trabajo de codificación real y hablando a otros desarrolladores sobre eso, es como aprendí lo pequeño, cosas de nivel muy bajo en lo que necesitaba ser muy bueno -pero también necesitaba ser muy bueno en la visión de alto nivel, y un montón de lo que leo es sobre el panorama general.

Usted necesita aprender a moverse rápidamente entre los detalles y el panorama general -debe estar moviéndose siempre, oscilando entre estos dos mundos.

Trato de mantener mi aprendizaje sobre el panorama general de cosas menos programáticas. Lo hago siguiendo lo que es interesante para mi.  Demasiada información nos envuelve y es fácil perderse y es fácil sentir que se está perdiendo demasiado tiempo vagando entre cosas aparentemente fortuitas que están flotando en el éter, sencillamente porque hay demasiado.

¡Pero es importante perderse!

Es importante que usted haga algo disperso. Esta es la razón por la cual tomar consciencia es una disciplina difícil de dominar -usted podría necesitar perderse ahora para ver con claridad después. Exige que usted confíe mucho en usted mismo y en el universo que le rodea. Pero si los monjes mendicantes pueden hacerlo, ¡usted también puede!

¿Por qué es importante tener la mirada en el panorama general?

Una de las características del arte del desarrollo de software es que en la medida que usted sea un mejor desarrollador, más alto es el nivel de abstracción en el cual trabaja.

Esto no significa que usted no pueda enfocarse y ser muy bueno en algún área específica, pero en mi opinión esto no es suficiente para ser un experto en cómo hacer algo. Sin duda yo fui un experto de clase mundial en Smalltalk cuando trabajaba en ese lenguaje. Pero al mismo tiempo estaba interesado en otras cosas.

Cuando Smalltalk pasó de moda el panorama general que yo había construido, mi visión en grande, contribuyó a los principios y prácticas que ahora conocemos como desarrollo de software ágil. Cada etapa de mi carrera ha madurado en las etapas que le antecedieron.

Cuando los conceptos de desarrollo ágil se juntaron por primera vez, todo aquello de vistas de alto nivel y patrones tuvo sentido para mí porque, conociendo la implementación de patrones en Smalltalk, ya había estado estudiando y pensando las cosas en un nivel más alto de abstracción.

Si desea realmente estar consciente sobre lo que usted está haciendo y hacia dónde las cosas se están dirigiendo, sobre el panorama general, entonces dedicará una importante cantidad de tiempo a aprender.

El valor de visualizar el panorama general es que aun cuando usted tenga la mirada sobre el código de algún proyecto, será capaz de percibir la llegada del momento mágico. De repente se dará cuenta y dirá, “un momento, he estado haciendo cosas en las que soy realmente bueno, pero si hago las cosas de esta otra manera ¡puedo triplicar lo que hago! ¡Incluso puedo quintuplicarlo!

Ir a los detalles y conseguir lo mejor de estos detalles en el código, le permitirán mejorar varias decenas de puntos. Pero ¿es esto suficiente? ¿Qué pasa si lo que estamos buscando es mejorar varias centenas de puntos? Al final realmente deseamos mejorar al máximo lo que estamos haciendo, no solo un poco. Las decenas suman, pero las centenas son el verdadero resultado de logros reales.

¿Cómo pensamos sobre algo de forma diferente?

¿Podemos tomar alguna cosa que alguien más descubrió en otra disciplina y aplicarlo a lo que estamos haciendo, de tal forma que conjuntos enteros de problemas se puedan resolver?  Esta clase de cambio y mejora  exponencial es a lo que nos referimos cuando hablamos sobre aprendizaje.

Para lograrlo, usted debe tener suficiente visión fuera de su pequeña área focal, debe ser capaz de ver estos grandes patrones cuando ellos están ahí, y aplicarlos.

Recuerdo cuando aprendí geometría en bachillerato. Aprendí los teoremas como los demás estudiantes. Podía, de algún modo, resolver problemas aplicando de memoria el “mejor” teorema. Era aburrido. Y tedioso.

También aprendí los principios y las abstracciones. Con esto a mi disposición podía resolver los problemas que me habían asignado aplicando los principios y las abstracciones. Era más difícil pero a la vez era más desafiante: ¿Cómo podía devolverme a las abstracciones fundamentales? Este aprendizaje me ha servido también para el desarrollo de software.

Posteriormente en la universidad volví a revisar problemas de física y seleccioné algunos interesantes para resolverlos con geometría básica, solo para ver como estos campos del conocimiento se relacionaban, atando los cabos sueltos, ejercitándome al alcanzar altos niveles de abstracción en dominios del conocimiento de los cuales no sabía demasiado.

Tuve la oportunidad de asistir a clases dictadas por Richard Feyman en Caltech donde pude mejorar algunas de estas habilidades. Como una muestra de lo que estoy diciendo puede revisar el libro “La conferencia perdida de Feynman” (Feynman’s Lost Lecture). En dicha conferencia él utiliza los conceptos más básicos de geometría y de física para mostrar por qué los planetas se mueven alrededor del sol describiendo trayectorias elípticas. obviamente yo nunca he alcanzado la habilidad de él, pero ayuda a mostrar lo que quiero decir.

En el desarrollo de software el uso de patrones es un ejemplo claro de la utilidad de la abstracción. Entendiendo las fuerzas y las restricciones involucradas permite tener soluciones bien conocidas.

Como desarrollador de software, los conceptos profundos y abstractos se me presentan todo el tiempo, y considero que el aprendizaje a este nivel es increíblemente importante para ser un desarrollador de software con consciencia.