Cuando asistí a la WordCamp London 2017, me sorprendió una charla de Adrian Roselli, Selfish Accesibility (o accesibilidad egoísta), que giraba en torno a una filosofía bastante sencilla: bien porque te hagas mayor o porque tengas algún contratiempo, algún día tendrás problemas que la accesibilidad resuelve, y te acordarás de tu yo joven cuando no la aplicó o le agradecerás haber pensado a futuro.

Esta filosofía caló en mí y le he ido dando vueltas desde entonces, aplicándola al desarrollo y a la gestión de proyectos: lo llamé Egoísmo Técnico y siempre bromeo con que es la manera de trabajar la mitad, cobrar el doble y producir 4 veces más. Por desgracia, no funciona así: no conozco ninguna empresa que te duplique el sueldo al producir 4 veces más.

Al principio, vi muchos paralelismos entre lo que comentaba Roselli en su charla y las buenas prácticas en el desarrollo y pensé que el Egoísmo Técnico es facilitar el mantenimiento y la escalabilidad del código gracias a las buenas prácticas.

Cuando escribo esto han pasado 7 años desde entonces y tengo claro que no es así.

Si la accesibilidad egoísta tiene que ver con facilitar(te) la vida a la hora de manejar interfaces y las buenas prácticas del desarrollo tienen que ver con facilitar(te) la vida con el mantenimiento y la escalabilidad del código, el Egoísmo Técnico tiene que ver con facilitar(te) el trabajo en sí mismo y, por lo tanto, no se trata tanto de realizar un trabajo pensando en los beneficios inmediatos que produce sino en los beneficios a largo plazo.

Aplicado al desarrollo, no se trata tanto de aplicar buenas prácticas y simplificar el código (por ejemplo) como de simplificar el propio proceso de desarrollo: usar librerías de componentes (crearlas si es necesario) en vez de simplemente desarrollar una interfaz, crear generadores de código en vez de implementarlo una y otra vez.

¡Oh! Lo sé, lo sé. No todo el código se puede generar. No lo hagas. Pero el que sí se puede, no lo implementes tú… ¡que lo haga una máquina!

Sé egoísta y entiende que tu tiempo es valioso, y que ese valor solo se percibe en la medida en la que se añade al trabajo que produces.

Dicho de otra manera, si automatizas los procesos, decisiones, implementaciones, etc. que es posible automatizar, liberas tiempo para centrarte en tareas de más valor.

Sé que estás pensando que tiene sentido y que es de cajón pero… ¿lo haces? ¿o se hace en tu empresa?

¿Cuántas excusas te vienen a la mente cuando lees esto? Porque, no te engañes, eso es lo que son.

Por cierto, que (te) facilites el trabajo no quiere decir que tengas que hacerlo por tu empresa (o por cualquier empresa).

Sé egoísta y facilita tu trabajo y tus procesos.

¿Beneficiará a tu empresa? Por supuesto.

¿Te beneficiará a ti? Mucho más.

Tus procesos se van contigo, así que el tiempo que dedicas a mejorarlos, optimizarlos y, sobre todo, automatizarlos, es para ti… para siempre, en todas las empresas a las que vayas.

El Egoísmo Técnico es para ti si…

1. Lo más importante es tu tiempo

Ya que no podemos producirlo, liberar tiempo es una de las actividades más importantes que podemos tener. Una importancia que crece cuanto más se asocia nuestro salario a nuestros resultados.

Pero, incluso si nuestro salario está asociado a nuestro tiempo (X dinero por jornada de Y horas semanales), liberar tiempo tiene beneficios como veremos en el punto siguiente.

2. Has tenido picos de trabajo que, o bien retrasan fechas de entrega, o bien suponen horas extras

Cuanto más desarrollo tienes que abordar manualmente, más sensible eres a los picos de trabajo, y si necesitas entregar en unas fechas determinadas, empiezas a descartar todo lo que no es «imprescindible».

Obviamente, si puedes negociar para extender los plazos todo lo que sea necesario, no vas a tener este problema. A mí nunca me ha pasado que se puedan extender hasta ese punto (aunque mis superiores directos hayan sudado sangre para conseguirlo), pero siempre hay una primera vez.

3. Te has «olvidado» de hacer cosas.

En general, cuando las prisas entran por la puerta, las buenas prácticas salen por la ventana. No haces tantos tests, ni documentas todo lo necesario, y se te olvidan algunas cosas.

En mi entorno, incluso sin tantas prisas, más de una (yo el primero) hemos olvidado cambiar la tarea en Jira de columna. Y, si bien es cierto que «no me pagan» por cambiar tareas de columnas, moverlas facilita la visibilidad del trabajo desde «arriba» y no queda bien que no tengas tareas en curso, o que las tengas demasiado tiempo.

Egoísmo Técnico aplicado

Al final, el Egoísmo Técnico se basa en:

1. definir todos los procesos que repitas más de una vez

Empezando por aquellos que más repites como, por ejemplo, crear ramas en un repositorio, documentar una funcionalidad, o implementar una batería de tests mínimos…

2. agrupar tareas similares,

Agrupar tareas similares permite, entre otras cosas, aprovechar un estado mental y un foco. Pero, además, te permite detectar patrones que se repiten y refinar los procesos que vas definiendo.

3. eliminar las tareas que estén repetidas o que sean redundantes,

Muchas veces, diferentes procesos implican pasos similares que, una vez agrupados, puedes abordar de una sola vez.

Un ejemplo muy sencillo es el aviso a los testers cuando se ha desplegado una nueva versión de una aplicación. En general, la aplicación tendrá un back y un front, pero solo avisaremos cuando se haya hecho el despliegue de todas las partes, en vez de avisar por cada parte.

4. automatizar todas las tareas de esos procesos que se presten a ello,

Automatizar no solo implica ahorrar tiempo. También ayuda a forzar estándares.

Si cogemos el caso de crear una nueva rama en un repo, es tan sencillo como usar un git checkout -b nombre-de-la-rama. Aunque nombre-de-la-rama puede ser cualquier cosa y eso puede no ser la mejor idea. Por el contrario, si automatizamos la creación de una nueva rama que nos pida los datos justos, se puede generar el nombre según un estándar pre-acordado.

Por supuesto, también podemos agrupar otras tareas del mismo proceso que estén relacionadas y que requieran los mismos datos… pero eso queda para otro artículo.