Hoy he leído un post de mi amigo Rubén: Cómo aprender cualquier cosa… rápido. Es curioso como cualquier persona con acceso a Internet se puede convertir en un experto en cualquier materia, como puede ser el caso de Julius Yego, campeón del mundo de lanzamiento de javalina que aprendió y mejoró su técnica de lanzamiento gracias a vídeos de Youtube. Por otra parte, en Twitter hay gente que con solo un tweet ya puede hablar de cualquier cosa creyéndose experto.

Definición de experto: El que sabe algo sobre algo que tú no sabes...

— Jorge Casas (@jorgecasas) September 12, 2013

Dándole vueltas al asunto: ¿Cuánto tiempo se tarda en ser experto en una materia?. Se suele decir que para convertirse en piloto experto necesitas 10000 horas de vuelo. En el post de Rubén (que surge tras ver una charla de Josh Kaufman), Josh asegura que con 20 horas puedes aprender lo suficiente como para saber por dónde te da el aire. Yo no me atrevería a pilotar un avión con solo 20 horas, pero sí que es verdad que en 20 horas (dedicadas y centradas en dicho aprendizaje) sabría por dónde seguir aprendiendo, por dónde buscar información o qué otros temas me interesaría aprender (es decir, sabría conceptos básicos: Un avión es eso que tiene alas… y de ahí ya podría buscar más información sobre navegación, motores a reacción o manuales de vuelo, según los intereses de cada uno…)

Sabe más el diablo por viejo que por diablo #refraneropopular #mehagoviejo #cuidado

— Jorge Casas (@jorgecasas) August 31, 2015

Esas 20 horas iniciales (y si pueden ser guiadas mejor) permiten tener una mínima base. Es el mismo ejemplo que suelo dar a la gente que quiere empezar a correr: Si eres capaz de correr un mes (que probablemente sean menos de las 20 horas netas indicadas), no serás campeón olímpico, pero notarás que te sientes mejor, tienes más resistencia, y no mueres al ir a tu casa y subir por las escaleras en lugar de usando el ascensor. Es una base, la cual también se puede perder si con el paso del tiempo no practicas.

Pero de esas 20 horas a las 10000 quedan 9980 horas de adquirir conocimiento y habilidades. Me hace gracia cuando leo en currículums que alguien es experto en cualquier tema con 1 ó 2 años de experiencia. Yo llevo desarrollando software y aplicaciones durante más de 15 años y me doy cuenta de todo lo que me falta por aprender… Y cada día más, puesto que hay nuevos caminos, corrientes, metodologías, lenguajes, sistemas… La tecnología avanza muy deprisa y el tiempo de aprendizaje es limitado.

Gente que conoces en persona y ves su perfil de Linkedin y les tienes que decir que añadan "Vendedor de humo" entre sus habilidades

— Jorge Casas (@jorgecasas) August 18, 2014

Conforme adquieres nuevas habilidades, conocimientos y herramientas, se abre un nuevo mundo de posibilidades, un nuevo conjunto de conocimientos por adquirir: La senda del conocimiento es misteriosa, pero un pequeño empujón (de 20 horas) puede hacer que cualquiera pueda comenzar a andar. Luego ya todo va rodado.

Hoy ha ocurrido una cosa curiosa: Hemos detectado un bug en una aplicación móvil. En algunos casos, los bugs suelen ser debidos a pequeños despistes o dislexias a la hora de escribir nombres de variables de las aplicaciones, pero en otros casos los bugs pueden ser los propios usuarios.

Muchos bugs son indetectables. Por muchos tests unitarios o de integración, el bug lo va a encontrar un usuario que hace cosas de manera habitual o un usuario que hace cosas de manera poco ortodoxa. En cualquier caso, el soporte técnico lo debe corregir (priorizando, claro está, según sea más o menos crítico).

Otros bugs son como ninjas: Están escondidos y nadie puede verlos, pero en cuanto aparecen te van a causar un destrozo. En estos casos, el problema no se da en prácticamente el 99% de los casos, pero para un estado dado el bug puede estar produciéndos (por ejemplo, una variable que toma un rango de valores específicos de entrada y para ninguno da problemas, salvo si el valor toma un valor de 7,2827 ). Por supuesto, en ningún test de pruebas se va a dar ese bug hasta que esté en producción.

Algunos bugs ni siquiera son bugs. Son deseos de los usuarios con ideas: Si a mí me parece que un botón debe ser de color azul y es de color amarillo, es un bug. Y como bug, se debe corregir…

Hay bugs tan complejos que se convierten en nuevas funcionalidades del sistema: It’s not a bug, it’s a feature!

Y por último están los bugs televisivos, en los que tú eres el protagonista:

• Bugs de CSI: Te hacen convertirte en un policía de CSI. Tienes que ir buscando pruebas (revisando logs) e ideando posibles escenarios del crimen, hasta que descubres que el usuario era el que estaba haciendo cosas raras o teniendo despistes como no tener el router encencido. En estos casos, y como buen policía, tienes que capturar al delincuente y juzgarlo.
• Bugs de Doctor House: En estos casos, tú eres el doctor House. Tienes un servidor o un sistema que falla, pero no sabes muy bien el porqué. Vas haciendo diferentes pruebas, analizando los resultados de dichas pruebas y creando diferentes teorías, hasta que descubres qué parte del sistema o servidor era el que estaba fallando y porqué y eres capaz de sanarlo y arreglarlo. O bien, se te muere el paciente, el sistema entero, el servidor, y todo el Internet. Incluso se podría prender fuego tu portatil en el intento.

En los últimos días hemos estado hablando en la oficina sobre optimizaciones. En el día a día de un desarrollador siempre tienes en cuenta las optimizaciones, pero muchas de ellas las introduces sin ni siquiera pensar: Es como conducir un coche y cambiar las marchas. Cuando eres un conductor experimentado entran solas, pero los primeros días que conducías por ti mismo tenías que mirar a ver dónde estaba el cambio de marchas para no meter la marcha de modo Rally cuando ibas por al autopista.

En muchos blogs sobre desarrollo puedes leer los típicos posts del tipo “10 cosas que debes hacer para que tu web sea más rápida”, o “7 cosas que todo desarrollador tiene que saber para que su web sea más rápida”, o “10 consejos que he copiado directamente de otro blog y que te recomiendo que sigas aunque no los haya yo probado en mis propias carnes”. Estos 10 consejos están bien, pero son los mismos en todas las páginas (y como ya se habrá podido apreciar, en muchos sitios no saben ni de qué están hablando).

Algunos de estos consejos tienen un mayor impacto que otros. Suelen ser del tipo:

• Usa API de terceros cuyas funcionalidades sean más rápidas y eficientes que si las tuvieras que ejecutar en tu servidor.
• A ser posible, no envíes HTML. Envía solo los datos en formatos como JSON, y que sea el navegador del cliente el que procese los datos.
• Sube los ficheros CSS y Javascript comprimidos. Y en un único fichero a ser posible. Y que carguen al final de la página.
• Usa CSS Sprites para sustituir imágenes de botones / iconos que sean muy utilizadas, para así realizar muchas menos peticiones. Y si puedes utilizar font-icons (fuentes de iconos) mejor, porque enviarás menos datos todavía y serás más cool.
• Sube imágenes comprimidas, y cuantas menos mejor.
• Comprime los datos que envíe Apache / Nginx / lighttpd con los módulos correspondientes para enviar cuantos menos datos posibles
• Cachea, cachea, cachea. Usa CDN (Content Delivery Network) donde sea posible.
• Y alguna cosa más así…

Con estas (y otras técnicas) se consigue que el sistema sea más fluido y rápido en la carga de datos y en el uso del sistema.

Hay que tener en cuenta que una de las optimizaciones que más se notan en cuanto a rendimiento es cambiar el sistema a una máquina / nube de máquinas más potentes, y esto hay que analizarlo en muchas ocasiones (sobre todo cuando toda la tecnología hardware se ha convertido en una commodity, y que el coste de mano de obra humana versus coste de mano de obra hardware es mucho mayor). Es decir, suele ser mucho más costoso optimizar un trozo de código que hacerlo correr en una máquina más potente.

Suena un poco triste, pero en el proceso de aprendizaje de desarrollo de código hay momentos en los que esto se convierte en una realidad: O haces un módulo nuevo desde cero, o pones una máquina más potente (porque meterle mano a un código que tiene ya varios años puede ser dañino incluso para la salud de los desarrolladores). Y cuando lo que se requiere es inmediatez, puedes levantar una máquina adicional con un click. Revisar código para micro-optimizarlo puede llevar días, semanas, meses… y no conseguir los resultados que se pretenden.

Por eso, a los nuevos desarrolladores siempre les decimos nuestro mantra KISS: Keep It Simple, Stupid… Cuanto más sencillo sea el código que vayas a desarrollar, más fácil será que sea óptimo. Y aun cuando creas que es el código óptimo, seguro que lo puedes refactorizar y optimizar. Y aquí volvemos a lo mismo: Habrá que analizar si es más eficiente optimizarlo, y qué coste tendrá dicha optimización.

Porque al final, todo depende del coste y de la rentabilidad que se pueda obtener con el código. En otros muchos blogs de desarrollo se habla (y se hacen estudios de eficiencia y rendimiento) sobre microoptimizaciones. Las microoptimizaciones son hacer pequeños cambios en el código (por ejemplo, usar un método u otro para obtener un mismo resultado o funcionalidad), que si se ejecuta una única vez apenas habrá una optimización de pocos micro o nanosegundos, pero que si se realiza un millón de veces se puede obtener una mejora de incluso segundos.

Eso sí, revisar miles de línea de código para introducir estas microoptimizaciones tiene un coste humano muy grande, por lo que estas microoptimizaciones son estúpidas en el 99,9999% de los casos. Conocerlas hace que al escribir código puedas utilizarlas de primeras, y entonces podrían llegar a tener sentido. Y puede ser que en algún caso muy muy crítico sean necesarias (en el 0,0001% de los casos restantes).

Pero hay otras optimizaciones que no se ven a primera vista. Ya no se tratan de estilos de desarrollo, ni de conocer mejor o peor el lenguaje utilizado, ni de saber cómo funciona a la perfección la arquitectura tecnológica que estás utilizando. Son pequeñas optimizaciones de usabilidad. Estas pequeñas mejoras las aprendes, en muchos casos, con el tiempo (porque sabe más el Diablo por viejo que por diablo…). Por ejemplo, haciendo que tras pulsar un botón de envío de formulario se genere un desplazamiento del contenido hasta el siguiente punto en el que el usuario tiene que actuar, evitándole que tenga que realizarlo él manualmente. Así puedes hacerle ganar al usuario varios segundos por click, y todo el tiempo que le haces ganar al usuario (que como ya hemos dicho, es mucho más costoso que el tiempo máquina) puede llegar a ser brutal, y más cuando la tarea la tiene que realizar miles de veces a lo largo del año.

Mediante el análisis de los procesos que siguen los usuarios se puede mejorar el interfaz de usuario (gracias a UX principalmente) para que sean estos los que menos tiempo pierdan. Es decir, la optimización muchas veces no depende de mejorar la calidad del código, ni de nuevas técnicas de procesado, sino que cambiando un botón de sitio puedes ser capaz de de hacer perder menos tiempo al usuario y gestor de la información. Y el tiempo es oro (al menos para algunos).