Hace ya unos años me llevé un baño de realidad al ver cómo fracasaban todas las propuestas de charlas que proponíamos en eventos de desarrollo o de metodología ágiles. Cosas que pensábamos que eran valiosas porque nuestro clientes valoraban e incluso nos hacía ganar mucho dinero parecían irrelevantes. Imaginad ejemplos:

– Características poco conocidas y útiles de Java.
– Fallos comunes utilizando Spring o Hibernate.
– Cómo implantar metodologías ágiles en una corporación.

Cuando fallas puedes hacer algo fácil: preguntar a distintas personas por qué creen que resultan poco atractivas y alguien me dio una respuesta sencilla y clara. Se la atribuyo a Abraham Otero de JavaHispano: la gente asiste a un evento movido por la novedad.

Lo vi cristalino, incluso eso puede hacer que tengamos más éxito en próximos eventos si el objetivo fueran “los números vanidosos”. Si pretendo que mi charla esté llena hasta los pasillos, o que en mi stand haya cola, sólo habrá que llevar unas Oculus o similar.

Pero hay una visión un poquito más profunda del tema porque egoístamente quiero AYUDAR A CREAR UN SECTOR DONDE PRIME LA CALIDAD Y NO EL PRECIO.

Si los que tienen mayor pasión por su profesión se centran más en lo nuevo que en la calidad del trabajo del día a día, se crea un vacío donde el trabajo de desarrollador lo ejecuta gente poco cualificada, sin referencias ni oportunidades de trabajar con calidad. Por tanto, el precio bajo por hora y el alto volumen constituyen las variables más importantes.

En este modelo sólo ganan las empresas más grandes, (obviamente los gerentes) y pierden todos los que alguna vez tuvieron ilusión por su profesión, (los buenos técnicos). Lo que me parece triste, es que no nos demos cuenta que el comportamiento individual afecta al colectivo.

Hay que buscar síntomas, ¿a cuántos informáticos conocéis apasionados por los videojuegos, el Internet de las Cosas o fotografía? Todos estos elementos requieren un aprendizaje continuo, una sensación de mantenerse en onda y hasta un prestigio social compartiendo. Es posible que esté equivocado, pero si los ambientes laborales no son satisfactorios, se buscan alternativas para el cerebro fuera de ellos.

Por tanto, la pérdida de ILUSIÓN provoca una difusión de FOCO que impulsa el arranque de un vórtice descendente.

Entonces, ¿qué podemos hacer? Una frase que leí el otro día en Twitter es “Para conseguir lo que quieres, deja de hacer los que no te conduce a ello” de Earl Warren.

En primer lugar tendríamos que concienciarnos acerca de nuestra responsabilidad sobre nuestro entorno de trabajo. No podemos permitirnos decir “es que esto funciona así” porque no es verdad. Nadie obliga a su equipo trabajar mal intencionadamente. La presión impuesta puede dificultar un desarrollo favorable de trabajo, pero si hay ligera presión continua y cada vez más aguda en sentido contrario, algo se gana (no digo que se resuelva a corto plazo).

El siguiente paso podría ser dejar la cueva y empezar a buscar a profesionales motivados: se identifican fácilmente en los eventos y en las comunidades locales. Pero claro, a lo mejor hay que empezar a organizar otro tipo de eventos menos “populistas”.

Si se desconoce dónde se quiere ir cualquier camino es incorrecto, por lo que definiremos una lista de cosas que podría ser interesante dominar, por ejemplo en el mundo Java:

– Novedades aportadas por las distintas versiones (y ya no hablo de la última que acaba de salir).
– Métricas de calidad de software.
– Programación concurrente. Impacto de los datos compartidos.
– Impacto de usar unas colecciones u otras en aplicaciones concurrentes.
– Orientación a objeto y patrones de diseño.
– Arquitecturas modulares.
– Control de errores y excepciones (que básicamente suele ser un desastre).
– Anti-patrones de diseño (saber cómo se hacen las cosas mal evita cometer dichos errores).
– Patrones de refactorización (ese menú que sale al pulsar el botón derecho de tu IDE).
– Programación con anotaciones.
– Conceptos de programación orientada a aspectos.
– Frameworks de persistencia, (aunque en mi opinión, su uso es desastroso).
– Herramientas de profiling y monitorización dinámica del sistema (como AppDynamics).
– Modelado de datos en base a dominios (grupos de campos preestablecidos).
– Optimización de consultas.
– Teoría subyacente del gobierno de servicios: definición, versionado, etc.
– TDD.
– Integración continua.
– Gestión automática de dependencias.
– Metodologías ágiles de desarrollo y principios de XP.

Así como mil cosas más.

Bueno, podríamos insistir y profundizar en ello pero es mejor plantearse algunas preguntas: ¿llevas muchos años trabajando o has repetido tu primer año unas cuantas veces?
¿Qué avances en técnica se han consolidado en tu departamento en el último año? ¿Alguien se preocupa de la gestión de conocimiento colectivo o cada persona solo del suyo? ¿Cómo se “fuerza” a que las nuevas incorporaciones trabajen bien desde el principio?

Sólo os deseo que recuperéis, el que lo haya perdido, ilusión y foco. Una estrategia común tampoco estaría mal.