Cada domingo tu bandeja de entrada se llevará una alegría

LSN112

Así machaco la productividad (más lento y con más errores)

Me siento sucio.

(Ahora te explico el motivo.)

El martes en el podcast hablamos de productividad y los sesgos cognitivos y te dije que hoy volveríamos sobre este tema, pero en negativo.

Podría haber caído en hacer una lista generalista, un "copy&paste" de domingo.

Sí, he copiado y pegado, pero desde la memoria.

He abierto carpetas viejas en el disco duro para que me trajeran recuerdos.

(Igual que cuando abres los armarios del desván y te acuerdas de los abuelos.)

Han vuelto a mi mente momentos de todo tipo, también alegres, pero he querido atrapar los peores. Como si fuera una mala pesadilla.

(Estos días no hago más que soñar, ¿te pasa a ti también?)

He visto suciedad.

Aunque hoy disfrute escribiéndote de esto, ha tenido un punto de amargura redactarlo.

He sentido desazón.

Pero creo que merece la pena medir la productividad personal echando la vista atrás, abriendo carpetas, no sólo revisando las frías horas imputadas en una hoja de excel.

📂 La multitarea "mola"

Querer hacer muchas cosas a la vez es algo normal.

En el desarrollo de software tiene algo de inocente y también algo de soberbia.

"Eso es una tontería, lo hago en dos patadas"

Esa frase resume ambas cosas.

¿Y cuántas veces se pasa por la cabeza?

Ha venido a mi memoria un proyecto que acabo de abandonar después de muchos años.

Surgió una vez un problema grave de seguridad y era necesario parchar unos ficheros. No teníamos estrategia alguna de despliegues.

Bueno si: toca por FTP.

Eso sí, disponíamos de un flamante espacio de testing para hacer pruebas.

Lo único que distinguía la carpeta de producción de la de pruebas era un número en la ruta. Si producción era web11, beta era web17.

Hablaba a la vez por teléfono con otra persona del equipo, tratando temas mundanos.

Subí el parche. Dormí feliz 100% seguro de haberlo hecho bien.

Al día siguiente teníamos un aviso de detección de ficheros maliciosos por parte del servidor.

El parche, por supuesto, estaba subido. A la carpeta equivocada.

Lo que iba a ser un día tranquilo, para seguir codeando con alegría se convirtió en una tortura.

📂 No hagas preguntas sobre lo que ya funciona

Los starters, boilerplates, templates, plantillas...

Esas píldoras de conocimiento disponibles siempre para "aligerar la carga".

Con multitud de herramientas ya conectadas. Todas hiperproductivas.

Minifican, archivan, despliegan, simplifican. Y también complican.

Las plantillas tienen algo de deidad. Les atribuimos poderes importantes, la infalibilidad.

El principal: hacernos la vida más sencilla, ahorrarnos tiempo, enfocarnos en lo importante, en nuestro código.

Muchas vecessi funcionan correctamente, porque están convenientemente probadas. También porque adoptan mejoras y issues (ya sea en el equipo o en el proyecto open source donde habiten).

Otras veces no.

"Maryo" era un boilerplate para crear aplicaciones con Backbone.

(Si, otra cosa antiquísima...)

Confieso que no teníamos ni idea de como funcionaba Backbone y Marionette.

Pero este generador lo prometía todo: generar vistas, modelos, colecciones...

Bueno, luego no fue así.

Más bien dedicamos horas a maldecir a su autor.

Hasta creamos una letra, sólo recuerdo el comienzo:

(Luego había insultos y cerveza, seguro.)

"Maryo, tu nos prometías ir como el rayo…"

Te enredas en intentar descubrir que estás haciendo mal.

Pero el que no tiene ni idea de qué hace aquello eres realmente tú porque quieres saltarte el aprendizaje.

Y porque no te has hecho ninguna pregunta relevante.

📂 Documentar es de cobardes

Siempre que hablo de documentación, bajan las visitas.

Es una palabra desafortunada.

No gusta reconocer que nuestra labor lleva implícita esa responsabilidad.

La documentación es considerada como algo anexo.

Imaginas tu software como un globo que tiene que ganar altitud. ¿Qué sobra? La documentación, tírala por la borda.

"Si lo hago siempre igual, para qué quiero documentarlo."

Para recordar esta frase con tanta claridad es muy probable que fuera yo el perpetrador de la misma.

Luego ocurren cosas. Durante largo tiempo nuestra documentación era el correo electrónico. No había tiempo para nada más.

Se asignaban tareas, se describían procesos y se confirmaban reuniones en la misma bandeja de entrada.

Outlook dio problemas. Algo pasaba con un fichero corrupto que no podíamos acceder al histórico.

Entramos en pánico. Nuestra "documentación" se había perdido para siempre.

A partir de ese momento aterrizamos en Trello y en Google Drive. Habrá herramientas mejores, seguro, pero aprendimos la lección.

📂 Orgulloso de que todo dependa de mi

Éramos un equipo remoto con un buen sueldo (o al menos eso me parecía).

Se decidió trabajar con una herramienta de alto nivel para dar servicio a los clientes. Era una forma de trabajar habitual en esa empresa.

El único que tenía cierta experiencia con ella era yo.

Así que empezaron las preguntas. Sin haberlo pensado me convertí en formador.

Estaba muy contento.

Pronto llegó una consecuencia muy evidente.

Si dedicaba gran parte de mi jornada a formar, no avanzaba con mi tarea. Como era remoto, también el tiempo libre empezó a ser lejano.

Ahí mi productividad se vio mermada.

Lo peor estaba algo más escondido.

"¿Qué plugin es el mejor?"

Es una pregunta muy habitual en esta fase. Tus colegas dudan, ven muchas opciones y se decantan según tu opinión.

Te hace sentir bien. Confían en ti. Lo notas.

Luego descubres que en tus manos está una responsabilidad que debería ser de equipo.

Recuerdo que había dos opciones para crear ecommerce. Me decanté por una en un proyecto pequeño. Luego esa decisión quedó marcada a fuego para el resto.

Durante meses ardimos en la hoguera prendida con ese fuego.

Una nota más

Antes de cerrar la edición de este newsletter he visto algo.

Otra forma de llamar a esto, mucho más trendy es: "make yourself replaceable".

Hazte reemplazable y te convertirás en irremplazable.

El penúltimo renglón

Guía para Desarrolladores en Remoto.

Así se llama este recopilatorio de herramientas y trucos que está construyendo Tomás Vilariño y que cuenta incluso con cuenta de twitter: @remotedevguide.

Me encanta como lo presenta, porque habla de esto que nos pasa como si fuera una película de ciencia-ficción.

"Las circunstancias que nos tocó vivir a principios del año 2020 condicionaron nuestra forma de vivir..."

¡Nos leemos el próximo domingo!

PD: ¿Es el Jamstack apto para ganarse la vida con él? Lo presenté hace semanas en el podcast, pero el martes profundizaremos sobre la aplicación real de los "frameworks de juguete".