La maldición del desarrollador: la responsabilidad infinita de quien tiene la capacidad de arreglar
(notashelf.dev)- Al repetir pequeñas automatizaciones, llega un punto en el que todas las herramientas y sistemas empiezan a verse como cosas que hay que arreglar: un umbral cognitivo
- Cuanto más crece la capacidad técnica, ya no solo se reconocen los problemas, sino que aparece el peso emocional de sentirlos como una responsabilidad
- El deseo de arreglar puede ir más allá de mejorar la productividad y convertirse en un medio para regular las emociones; a veces incluso termina haciendo que uno quede atrapado en los sistemas que creó
- Con el tiempo, los sistemas inevitablemente se deterioran, y no existe la fantasía de una solución perfecta
- Al final, la verdadera habilidad necesaria no es poder arreglarlo todo, sino tener la calma mental para soportar que algo no se arregle
Todo empieza con una pequeña automatización
- Comienza con pequeñas mejoras de productividad, como un script de Python para cambiar nombres de archivos o atajos para comandos de
git - Después de corregir directamente las incomodidades del sistema, todo en el mundo empieza a parecer candidato a ser mejorado
- En algún momento, deja de ser “puedo hacerlo” y se convierte en la compulsión moral de que “debo hacerlo”
El peso de la capacidad técnica
- Antes de programar, uno podía pasar por alto un software incómodo, pero ahora los problemas se ven con total claridad
- El código descuidado o las configuraciones hardcodeadas hechas por otros desarrolladores se sienten casi como una afrenta
- Se produce un cambio de percepción en el que todos los sistemas y programas parecen una lista de TODO de cosas por arreglar
La vida de refactorizar sin parar
- Cada vez aparece la idea de “yo podría hacer esto mejor”, y uno termina absorbido por crear sus propias herramientas
- Directorios de código desordenados, innumerables intentos y abandonos, y rediseños estructurales interminables pueden convertirse en trabajo autoimpuesto y restrictivo
- Como en la metáfora de Kafka de “construir una jaula y esperar al pájaro”, uno puede caer en la fabricación de herramientas sin propósito
El software se pudre
- Incluso un script que parecía perfecto algún día deja de servir por cambios externos
- cambios en el layout de un sitio web, cambios de versión de paquetes, errores de dependencias, etc.
- Cuando surge un problema, ya no se siente como una simple molestia, sino como culpa
- Al final, uno se enfrenta a la realidad de que todo requiere mantenimiento continuo
La fantasía de la automatización
- Es común aferrarse a la falsa esperanza de que “si lo configuro una sola vez, ya no tendré que tocarlo nunca más”
- Se piensa en la programación como una victoria de resolución de problemas, pero en realidad es solo una guerra que no termina
- No existe algo como el estado finalizado; solo estamos cavando trincheras que siempre vuelven a inundarse
Cuando programar se vuelve una forma de regular las emociones
- Crear herramientas a veces es una respuesta psicológica para intentar controlar el caos de la vida
- Cuanto más complejo es el sistema, más sensación de orden puede llegar a sentir uno mismo
- Para escapar de una vida complicada, se prueban nuevas apps o refactorizaciones y se obtiene consuelo personal
El burnout que llega sin aviso
- El burnout no proviene solo del exceso de trabajo, sino de un sentido de responsabilidad excesivo
- El autorreproche de “si puedo arreglarlo, ¿por qué no lo hago?” intensifica el estrés
- Esa responsabilidad técnica interminable termina actuando como una carga autodestructiva
Aprender a soltar
- No hace falta resolver todos los problemas
- A veces, saber que no es necesario arreglar algo es una forma de control aún mayor
- Aceptar los defectos y simplemente usar las cosas tal como son también puede ser una elección consciente
La verdadera habilidad es la claridad emocional
- Más importante que la habilidad de arreglar es la capacidad mental de no tener que arreglar
- La capacidad de distinguir cuándo detenerse y qué proyectos son solo una forma de consuelo personal
- Hace falta una actitud que permita salir de la obsesión por arreglarlo todo y encontrar comodidad incluso en la imperfección
Al final, la habilidad más difícil en programación es
"aprender a dejar algo roto tal como está"
21 comentarios
Todo tiene un propósito. Si ya se cumplió, no hace falta seguir arreglándolo. Pero si no se ha cumplido, hay que arreglarlo.
Parece que el punto de partida es entender con claridad el propósito del proyecto.
Es más fácil de asumir cuando te das cuenta de que incluso hay empresas que valen cientos de miles de millones solo por encargarse de agrupar y ordenar las APIs hechas un desastre de bancos y procesadoras de pagos jaja
Cux..
Si al ver que un sistema hecho con VB 6.0 y COM + OLE + ActiveX todavía funciona perfectamente te horrorizas y te dan ganas de reescribirlo, entonces tú eres quien va a sufrir.
Al final, la habilidad más difícil en programación es
aprender a "dejar en paz lo que está roto".
Totalmente de acuerdo. Soy del tipo que siempre se mete a hacer cosas, así que siempre termino sufriéndola...
La automatización improvisada que arma cualquier programador, por supuesto, inevitablemente se va a romper.
Buen contenido
Agotamiento punto dem
: cuando automatizaste el trabajo con mucho esfuerzo, pero quien ve el beneficio es el compañero de al lado y, al final, a ti te asignan a automatizar otras tareas;
Soy una de esas personas que automatizó en 2 días una tarea que toma 15 minutos, y sí, soy un auténtico robatiempo del sueldo.
El exceso de sentido de responsabilidad es como una enfermedad ocupacional de los programadores, así que hay que resolverlo con el sistema.
El equipo de Quality Assurance es el que debe asegurar eso.
¿QA puede ayudar a frenar el exceso de sentido de responsabilidad de los desarrolladores? No lo entiendo bien, así que pregunto.
Si a los desarrolladores se les empieza a señalar la culpa diciendo “programaste mal”,
terminan abrumados por la responsabilidad y evitan intentar cosas nuevas,
y al final solo escriben código seguro, sin avances.
Por eso QA debe asegurar eso.
Para hacer código que impulse mejoras, inevitablemente hay que asumir cierto nivel de riesgo,
y quien debe validarlo y hacerse responsable de ello tiene que ser QA.
¿Así también se puede leer este artículo? Yo pensé que, si nos ponemos estrictos, este artículo más bien criticaba el yak shaving.
Como dijo roxie, hablar del texto en sí ciertamente corresponde a la idea de yak shaving,
pero al compararlo con mi experiencia personal, terminé contando algo un poco distinto de lo que plantea el texto.
¿No podría explicarse también por el fenómeno NIH (
not invented here)? Creo que no debemos olvidar que el mantenimiento termina siendo un costo fijo y que dentro de ese costo también se incluye el esfuerzo de las personas.Para poder hacer esto durante mucho tiempo, parece que también hace falta practicar de vez en cuando cómo soltar un poco el peso de la responsabilidad y de las emociones antes de caer en el círculo de la sobrecompensación por un exceso de sentido de responsabilidad.
A mí también es algo que no se me da muy bien regular jaja... buen contenido.
Creo que este es un buen punto. La responsabilidad, literalmente, consiste en sentir responsabilidad, así que por sí sola no suele exigir una compensación. Pero con el tiempo, mientras el cuerpo y la mente se agotan, la responsabilidad no desaparece fácilmente, y para llenar esa brecha parece que uno empieza a esperar una compensación (aunque en realidad no deberían conectarse así). Sin darse cuenta.
Bueno, supongo que un punto medio un poco mejor que "dejar las cosas rotas tal cual" sería "no lo toques hasta que se rompa" :)
Opinión de Hacker News
Hay una cita que aprendí cuando hacía teatro. Explicaba que el proceso del arte consiste en convertir lo difícil en un hábito, lo habitual en algo fácil y lo fácil en algo bello
Presenta una opinión personal sobre los problemas de UI
Expresa dificultades con los proyectos personales
Expresa respeto por los ingenieros de software
Presenta una crítica al perfeccionismo
Comparte una reflexión personal
Menciona que la familia y los hijos ayudan a resolver el perfeccionismo
Escribir software directamente es más divertido y ofrece soluciones más simples
Afirma que la cultura de obsesionarse con lo nuevo es la raíz del problema
Los psicólogos clasifican a las personas entre quienes buscan maximizar y quienes buscan algo suficientemente bueno
Parece que una frase más adecuada que "cómo dejar algo roto tal como está" sería "cómo soltar lo que no es importante".
Lo que realmente hay que arreglar, hay que arreglarlo.
Me identifico. Creo que uno debe saber bien si está embelleciendo más su jardín o si realmente está haciendo un trabajo importante, y aprender a soltarlo.