- La habilidad de desarrollo no se determina solo por el conocimiento; incluso si sabes qué hay que hacer, si pospones pruebas, refactorización o la creación de casos reproducibles por falta de motivación, la deuda técnica se acumula
- Los grandes desarrolladores investigan y corrigen los
flaky tests, convierten los bugs que encuentran en tickets o los arreglan de inmediato, y si una nueva funcionalidad no encaja con el código existente, primero refactorizan - Refranes como “premature optimisation”, “duplication is better than the wrong abstraction” y “Keep It Simple, Stupid” son útiles para lidiar con restricciones reales, pero también pueden usarse para esconder el simple hecho de no querer hacerlo
- En Lazygit, durante varios meses se construyó un sistema de pruebas end-to-end y se sintió su impacto, pero en Lazydocker no se añadieron esas mismas pruebas, y también se fueron postergando la solicitud de un repositorio mínimo reproducible y la refactorización de un God Struct
- Incluso cuando no tienes la energía para escribir código perfecto, si muestras con honestidad qué partes quedaron cortas, es más fácil juzgar el estándar de mantenimiento y priorizar el siguiente trabajo
La falta de motivación que genera deuda técnica
- “Can’t Be Fucked” es una expresión coloquial australiana que significa no querer hacer algo o no tener la energía y motivación para hacerlo
- Pensaba que aprender mucho conocimiento de desarrollo me convertiría en un mejor programador, pero en la práctica los desarrolladores que termino admirando son personas que, además de conocimiento, tienen constancia y disciplina
- Los buenos desarrolladores saben y actúan con base en que abordar bien los problemas cuando aún son pequeños ahorra tiempo a largo plazo
- Si hay un
flaky test, lo investigan y lo corrigen - Si encuentran un bug en producción, crean un ticket o lo arreglan de inmediato
- Si una nueva funcionalidad no encaja con el código existente, primero refactorizan en lugar de meterla a la fuerza
- Si hace falta, bajan hasta las capas inferiores del stack para encontrar la causa raíz
- Si hay un
- Estos desarrolladores también saben distinguir cuándo “good enough” es suficiente, cuándo hay que recortar alcance y cuándo conviene aprender más del dominio antes de cambiar la arquitectura
- El problema es que, aparte de ese juicio, a veces la falta de motivación se vuelve una restricción más fuerte que las limitaciones externas del proyecto
Ser honesto en vez de esconderse detrás de refranes
- El sistema de pruebas end-to-end de Lazygit se construyó a tiempo parcial durante varios meses, luego evitó muchas regresiones, y existe la certeza de que habría sido más difícil añadirlo más tarde
- Aun así, la razón por la que no se añadieron pruebas end-to-end a Lazydocker fue simplemente CBF
- Después de abrir un issue en otro repositorio open source, se pidió un repositorio Git mínimo reproducible, pero todavía no se ha creado; además, una gran refactorización iniciada hace más de un año sigue sin terminar, así que gran parte del código todavía permanece en un God Struct
- No se concluye si esto es burnout, falta de mentalidad de crecimiento o un tema de personalidad
- Saber el dolor a largo plazo que causa la deuda técnica puede motivarte a evitarla, pero saberlo y actuar correctamente en la práctica no son lo mismo
- Frases como “demasiadas pruebas generan carga de mantenimiento”, “voy a refactorizar después de ver cómo impactan otras funcionalidades”, “premature optimisation” y “cut scope aggressively” pueden usarse para un buen juicio, pero también como excusas
- Si reconoces que una parte del código o del pull request quedó floja por pereza, el revisor puede juzgar directamente si esa carencia supera el estándar o si conviene más dedicar tiempo al siguiente trabajo
- Cuando llegue ese estado de CBF, en vez de desanimarte, conviene ser honesto; y si llevas demasiado tiempo corriendo al 100%, quizá necesites vacaciones
1 comentarios
Comentarios de Hacker News
Una parte considerable del CBF puede explicarse solo con la compensación y los incentivos
Cuando entré a mi empresa actual, estaba lleno de energía: arreglé builds rotas, hice pasar pruebas abandonadas, refactoricé el pipeline de despliegue y encontré y corregí la causa raíz de bugs
Pero con el tiempo, la gente, lejos de seguir mi ejemplo, pasó a pensar “igual esa persona lo va a arreglar”, y entendí que si haces el trabajo pesado, solo te cae más trabajo pesado
En cambio, quienes construyen cosas a las apuradas, como con hacks, empaquetan bien los resultados y ascienden primero; para cuando explotan los problemas en operaciones, ya se movieron a otro proyecto
El junior al que ayudo varias horas cada semana gana más que yo porque lo contrataron de urgencia en 2022, y aunque en 2023 recibí una evaluación de “supera las expectativas”, no me dieron aumento porque eran tiempos difíciles
Al final, desde la perspectiva de alguien que trabaja por un sueldo, si el esfuerzo no se recompensa o incluso se castiga, no es raro que desaparezca la motivación
Deberías irte y encontrar el lugar donde puedas estar, y a tu gente
Cuando hay reconocimiento, el costo de motivación baja mucho, y a las personas les gustan las recompensas
La gente pasa miles de horas jugando porque el costo de motivación es muy bajo
No digo que haya que gamificar el trabajo, pero defenderse a uno mismo puede verse mezquino, así que los compañeros deberían reconocerse mutuamente
En la deuda técnica también hay distintas tasas de interés, y la habilidad está en dejar la deuda al 0% y pagar primero la de alto interés
Cuando estaba poniendo el piso del clóset del sótano, me quedé corto de materiales y no pude cubrir por completo la parte de atrás; se ve un poco feo, pero siempre está tapado con cajas y aunque viviera allí décadas no tendría impacto. Eso es deuda técnica al 0%
En cambio, si se tapa el desagüe, con el tiempo el costo crece por filtraciones en el sótano o por el desprendimiento del desagüe, así que es una deuda que acumula interés. Si los escalones de entrada están dañados y uno se tropieza todo el tiempo, también es una deuda de alto interés que hay que arreglar rápido
En ingeniería, un problema de arquitectura que retrasa el desarrollo de todas las funcionalidades puede ser deuda de alto interés, mientras que el código sucio o los TODO en un archivo que casi no se toca pueden ser en realidad deuda de bajo interés
Los ingenieros, por un lado, se pierden trabajos más importantes por arreglar deuda al 0%; por otro, dicen que “producto/liderazgo no apoya resolver la deuda técnica”, pero muchas veces no logran explicar bien el costo real ni la tasa de interés
De arriba abajo, solo llama la atención lo nuevo y brillante, y no hay interés en mantener lo existente
Incluso si convences a la dirección de su importancia, ellos solo estarán de acuerdo en que el trabajo es necesario, pero no tendrá ningún impacto positivo en la evaluación de desempeño. Termino haciéndome cargo de algo por lo que solo me van a regañar si sale mal
Si una base de código está desordenada y es inconsistente, aunque sea en archivos ocultos, los desarrolladores pierden las ganas de implementar nuevas funcionalidades con consistencia y calidad
Se convierte en “igual hay que reescribir todo este módulo, así que por ahora peguemos esto aquí de cualquier forma y después lo limpiamos”
https://en.wikipedia.org/wiki/Broken_windows_theory
Es una extensión natural de la expresión deuda técnica, transmite el punto de forma concisa y me gustaría usarla también en la empresa
Por eso culpar a que “el desarrollador no explicó el costo real” es una excusa un poco fácil
Si surge un problema visible para el cliente, es probable que se resuelva, pero si es solo un problema interno, la probabilidad baja mucho
Cuando se usa en serio una expresión como “deuda técnica al 0%”, quizá conviene preguntarse si no se entendió mal el concepto
Una deuda hay que pagarla o hay que pagar intereses; si no existe nada de eso, no es deuda
A este paso, la próxima vez dirán que una funcionalidad aún no implementada también es deuda técnica al 0%
No soy fan de Steve Jobs, pero siempre me gustaron sus citas sobre la artesanía y la atención al detalle.
“Si eres un carpintero que hace una hermosa cómoda, no vas a usar madera contrachapada para la parte de atrás solo porque queda contra la pared y nadie la verá. Tú sabes que está ahí, así que también usarás una madera hermosa en la parte de atrás. Para dormir tranquilo por la noche, la estética y la calidad tienen que mantenerse hasta el final”.
Creo que el software en general sufre mucho por la actitud de “ya cumplí técnicamente con los requisitos a duras penas, así que mi trabajo terminó”.
https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...
Hay muchas historias de que se negaba a lanzar hardware y software que no cumplían con el estándar, y que despedía a quienes no lograban hacerlo con las especificaciones correctas.
En cambio, la mayoría trabaja bajo el liderazgo exactamente opuesto: “terminen lo más rápido posible para vender más, y ajusten más o menos lo necesario para que las pruebas de calidad pasen sin problemas”.
Un carpintero real tiene que ser práctico y rentable para competir en el mercado.
Si usa madera cara o dedica tiempo a lugares que nadie ve, reduce su rendimiento y aumenta innecesariamente el costo para el cliente.
Incluso para un artesano, el tiempo y el dinero son finitos, y el tiempo dedicado a trabajo invisible es tiempo que no se dedica a trabajo más visible.
En un mercado donde carpinteros con la misma habilidad producen más a menor costo, ese carpintero quedaría desplazado.
Creo que el problema del software tiene que ver más con incentivos que con actitud. Me gusta hacer buen trabajo y usar buen software, pero las horas del día son limitadas y no voy a sacrificar mi tiempo personal por un beneficio de negocio del que no voy a sacar provecho.
Además, si empiezo una refactorización, es razonable esperar que cualquier día aparezca de repente una funcionalidad indispensable que hay que terminar hoy mismo.
Aunque la gerencia esté de acuerdo en resolver la deuda técnica, al final no se resuelve a menos que infles las estimaciones y refactorices en lugar de hacer el trabajo asignado.
En un libro, un personaje herrero arregla una pieza de una carreta y dice: “Siempre haz lo mejor que puedas”.
Cuando le dicen: “Pero es una pieza que va abajo, nadie la va a ver”, responde: “Pero yo sé que está ahí. Si no la hago tan bien como puedo, me avergonzaré cada vez que esa carreta pase. Y voy a ver esa carreta todos los días”.
https://news.ycombinator.com/item?id=28086786
Si escribes buenas pruebas unitarias/de integración/end-to-end, y cuando ves código desordenado lo refactorizas en vez de poner más cosas encima, en el papel eres menos productivo que un colega que sigue “resolviendo” tickets.
Esto es especialmente grave en organizaciones “totalmente ágiles” que no consideran en absoluto la refactorización ni la limpieza de calidad de código.
Apple fue una excepción, al menos durante un tiempo. Sus productos tenían precios altos, los clientes esperaban calidad, la empresa tenía los márgenes para hacerlo posible y, sobre todo, tenía a Steve Jobs, que sabía ver la experiencia.
En el extremo opuesto también hay casos como Juicero, que construyó una máquina para exprimir paquetes de jugo con ingeniería de nivel aeroespacial.
Durante la mayor parte de mi carrera, cada vez que veía una oportunidad limpiaba deuda técnica aunque nadie me lo pidiera. Era porque tenía apego y sentido de propiedad.
Ahora estoy en un lugar de trabajo basado en Jira, con micromanagement y sin autonomía, así que no hago nada más allá de lo estrictamente necesario.
Antes, el esfuerzo voluntario era una parte central de mi carrera, pero ahora cualquier cambio tiene un costo burocrático y social de gestión de proyecto tan grande que no vale la pena.
No me importa si al producto le va bien a largo plazo o si la empresa tiene éxito; solo despacho tickets hasta encontrar mi próximo trabajo.
En cambio, si avanzas con la idea de “la refactorización se hace sin pedir permiso”, te regañan por crear un PR que no sigue los patrones existentes del repositorio.
Termina siendo: “Está bueno, pero hay que discutirlo con todo el equipo”.
Así la deuda técnica sigue creciendo, fusionar un solo PR toma meses y las pruebas son tan inestables que presionar el botón de reinicio hasta que compile parece una tragamonedas de casino. Agile es realmente maravilloso.
En mi experiencia, actuar de forma proactiva en un lugar de trabajo que solo se mueve reactivamente jamás se recompensa.
Si detectas un problema, en ese momento se convierte en tu problema, y si más adelante vuelve a explotar, pasa a ser algo que tú arruinaste.
Los PM y la gerencia siempre operan con supuestos negativos, así que no vale la pena.
En especial, algunas personas creen tener un camino iluminado hacia el buen código, pero en realidad muchas veces eligen el camino más fácil en vez de leer y entender el código existente.
En los comentarios aquí hay algunos malentendidos.
Para un programador individual, la motivación, el esfuerzo, la energía o la fuerza de voluntad —como quieras llamarlo— son recursos finitos, y eso es completamente normal.
La ventaja de una organización es que logra hacer más que un programador individual, pero al conectar varios elementos aparecen huecos y el trabajo se cae por ahí.
Las personas a las que se les paga por operar la organización, no por trabajo técnico —como COO, RR. HH. o product managers— deberían crear procesos para cubrir esos huecos.
Pero cada vez más empresas trasladan ese trabajo a ingenieros y diseñadores individuales, porque es difícil medirlo con ganancias y pérdidas u OKR.
La empresa sufre y los ingenieros se queman. Hay un límite para seguir haciéndose cargo, sin compensación adicional, de pequeños tickets y tareas que se cuelan por las grietas.
Hay muchísima negatividad por aquí, pero me dio gusto leer este texto porque describe exactamente cómo me siento en el día a día.
Cuando veo la excelente cobertura de pruebas y las refactorizaciones con principios de proyectos open source, algunos días entro en modo “hagámoslo bien” y logro hacer muchas cosas bien construidas.
Pero cuando un día esa energía desaparece, termino como el autor: en modo CBF. Me salto las pruebas, agrego código en lugares que sé que no son buenos y voy pavimentando un camino que mi yo del futuro no va a agradecer.
Lo veo pasar en tiempo real, pero no tengo la energía ni la motivación para volver a ese modo inspirado de “hagámoslo bien”.
Todo esto pasa incluso en el software que yo mismo creo y vendo.
Me impresionó ver que el autor es quien hizo Lazygit, y lazygit me encanta. En mi cabeza siempre ha estado en la categoría de mantenedores open source que hacen las cosas bien.
Parece que ambos tenemos experiencias parecidas con la motivación.
Me alegra que te guste lazygit, y espero poder mantener esa buena opinión en el futuro.
La mayoría de las decisiones en realidad son inconscientes.
Estar en un estado de “de plano no puedo hacerlo” significa que algún circuito del cerebro juzga que cosas como refactorizar o escribir pruebas no valen la pena.
Ese circuito podría tener razón. Porque, visto de manera objetiva y global, muchas veces la recompensa realmente no compensa el esfuerzo.
Por ejemplo, si pasaste dos meses creando pruebas end-to-end y luego, durante los siguientes seis meses, ahorraste tres semanas en debugging y cosas similares, las cuentas no cierran.
Hay dos extremos comunes. De un lado, el negocio obliga a los ingenieros a aceptar deuda técnica que es un compromiso realmente malo; del otro, los ingenieros a veces dedican tiempo a una estructuración ideal y a enormes paquetes de pruebas que al final no serán recompensados.
Parte de eso también ocurre porque a alguien le preocupa que encuentren una mejor estructura de código o pruebas adicionales y lo evalúen por ello.
Si siento que estoy entregando algo por debajo de mis estándares, aunque esos estándares sean más altos de lo realmente necesario, eso daña mucho la moral y la motivación.
Creo que el mayor problema de la deuda técnica es, más bien, que destruye la moral.
En Lazygit construí parcialmente durante meses un sistema de pruebas end-to-end, y todos los días pienso en las regresiones que ese sistema evitó y en lo mucho más difícil que sería agregarlo ahora.
Aunque sé perfectamente que valió la pena, la razón por la que no agregué pruebas end-to-end a Lazydocker es simplemente que estoy en modo CBF.
Las pruebas end-to-end son infernalmente molestas y requieren muchísimo trabajo si no tienes buenas herramientas. Hace falta que mejoren los frameworks base que se puedan integrar fácilmente.
Si tienes suerte, a esa persona le quedará tiempo para ver también pruebas de integración.
Creo que la forma en que esta sociedad y este mundo ven a la gente como floja es, en general, absurda.
Es como trabajar 40 horas a la semana durante décadas y descansar solo después de reencarnar; ¿y aquí quieren hablar de flojera?
Nos exprimen la energía mental para crear riqueza ajena, y cuando estamos demasiado viejos para hacer algo nos desechan.
Cada semana aparece otra funcionalidad que debía estar lista ayer, y no sé cuándo se supone que hay que arreglar la deuda técnica. ¿En el tiempo libre? Ni siquiera sé por qué deberíamos seguir existiendo, para empezar.
En un proyecto maduro de un equipo pequeño, todos los tickets que quedaban eran bugs difíciles que nadie quería.
Bugs en los que puedes invertir días y no tener nada que mostrar salvo haber tachado algunas hipótesis, o tachar la equivocada y que una semana después vuelva el problema.
Todos los días tienes que volcar toda tu energía mental en esos tickets, y cuando por fin logras resolver un bug a punta de café o estimulantes, envías el código, cierras el ticket y pasas directo al siguiente.
No hay descanso real; solo al inicio del siguiente ticket puedes relajar un poco la cabeza, cuando nadie espera resultados inmediatos.
Pero después de unos días la gente empieza a preguntar qué has hecho hasta ahora, si estás bloqueado, y tienes que inventar pequeñas mentiras para explicar por qué vas atrasado cuando en realidad casi ni has podido empezar.
Cuando más necesitas descansar, ya es cuando más atrasado estás y la gente ya se dio cuenta, así que incluso tomarte vacaciones no se siente como una opción.
Ahora trabajo entre 20 y 30 horas por semana, a veces menos, en una organización sin fines de lucro de ingeniería, y el dinero alcanza justo, pero trabajar más me resulta imposible.
Tengo algo de tiempo para proyectos personales y para andar en bicicleta, y jamás trabajo los fines de semana. Tampoco trabajo los martes, salvo casos especiales.
Amo de verdad mi trabajo actual y es mi trabajo soñado, pero no vale la pena matarme por él. Solo hay una vida, y voy a vivirla amando bien.
Hoy terminé una tarea de un mes en la que prácticamente reescribí por completo el firmware de un dispositivo de la empresa, aunque al principio estaba estimada como una tarea de una semana para corregir un pequeño bug en parte del módulo de comunicación.
Por suerte tengo un PM y compañeros relajados, así que reconocieron que ahora realmente podemos arreglar bugs legacy de 8 años en ese código.
Todavía faltan pruebas de casos límite y correcciones adicionales, pero como la actualización remota de código ya funciona, podemos despachar el dispositivo.
Aquí “mentir” es casi una recomendación de acción. Originalmente empecé el comentario con “miente”, pero hubo malentendidos.
También hay que existir para mostrarles a nuestros colegas que es importante tomarse tiempo para pensar en las implicaciones más amplias del trabajo.
Y para aportar tus ideas a comunidades como esta, comer chocolate, sacar a pasear al perro si puedes y escuchar conferencias de Alan Watts en YouTube.
Como alguien que intenta hacer las cosas bien, creo que lo importante con la deuda técnica es el seguimiento.
Convertir un problema visible en una tarea toma solo unos minutos, y esa tarea se vuelve deuda técnica.
El liderazgo tiene la responsabilidad de priorizar la deuda técnica y reducir una cierta cantidad de forma continua.
A veces también se reduce la deuda técnica decidiendo no hacer algo, y eso está perfectamente bien.
El propósito del proceso de registrar, revisar y resolver es dar una segunda oportunidad de mirar los problemas que “no son para ahora”.
Puede que la primera intuición haya estado equivocada y X no fuera necesario, o al contrario, que sí lo fuera por razones que en ese momento no se nos ocurrieron.
Sobre todo, algunas de las cosas que “no podemos hacer ahora” sí son realmente importantes. Si no te tomas el tiempo de revisarlas, no podrás encontrarlas.