No hacer nada en el trabajo

• El desempeño de un ingeniero de software depende menos de pasar más tiempo o escribir más código, y más de hacer trabajo de alto impacto en el momento adecuado; por eso, en la rutina diaria, puede ser útil operar al 80% y pasar alrededor del 20% de la jornada lejos de la computadora
• En organizaciones de ingeniería grandes, las oportunidades dependientes del tiempo —como apoyar un gran contrato, mitigar un incidente o lanzar una funcionalidad clave— pueden crear mucho valor, y si ya estás ocupado es fácil perderlas
• Si sigues resolviendo tickets de baja prioridad, dejas de ver lo que ocurre en otros equipos, las actualizaciones del equipo o los incidentes en curso, y a tu manager también le cuesta identificarte como alguien con disponibilidad
• El tiempo de no hacer nada permite recuperarse del estrés, mantener la calma durante la respuesta a incidentes, generar nuevas ideas y tener concentración para el trabajo importante
• Dejar capacidad libre de forma intencional en la rutina y comprometerse al 100% solo en momentos de recompensa muy alta crea mejores condiciones para convertirse en un ingeniero de alto rendimiento

---

Oportunidades de alto impacto

• Muchos ingenieros deberían trabajar menos; eso no significa escribir menos código o hacer menos cambios, sino reducir el tiempo real de trabajo durante el día y trabajar a un ritmo más lento cuando sí se trabaja
• En el estado base, el objetivo es una utilización del 80% y, cuando no hay proyectos de alta presión, pasar el 20% de la jornada lejos de la computadora
• El desempeño en una empresa tecnológica está muy influido por eventos poco comunes, y muchos de los cambios que más impacto generan pueden requerir sorprendentemente poco trabajo
• En el desarrollo de software no se premia el esfuerzo por sí mismo; lo importante es resolver el problema correcto en el momento correcto

• Tres casos posibles en una organización grande

  • Apoyar una funcionalidad o una corrección de bugs justo cuando se intenta cerrar un gran contrato enterprise puede ayudar a concretarlo
  • La funcionalidad no tiene que ser excelente; en algunos casos basta con demostrar la voluntad y la capacidad de hacer un cambio específico
  • Prevenir o mitigar un incidente en sus primeras etapas puede reducir la pérdida inmediata de ingresos durante el incidente, así como la pérdida posterior por churn de clientes o rechazo de contratos
  • Solo saber que había que desactivar el feature flag correcto puede ahorrar una gran cantidad de dinero
  • Cuando la empresa intenta lanzar una funcionalidad importante, el éxito o el fracaso puede depender de un cambio pequeño pero difícil de encontrar
  • Algunos ejemplos son agregar rápidamente un campo nuevo a la configuración del usuario, o corregir una vieja función de exportación de datos enterprise que nadie toca desde hace años
  • La familiaridad con el sistema puede marcar la diferencia entre un cambio que toma unas horas y otro que toma una semana

• Dependencia del tiempo

  • Todas estas oportunidades son dependientes del tiempo; no puedes iniciar sesión por la mañana y resolver al azar un gran contrato, mitigar un incidente o crear rápidamente una funcionalidad clave
  • No basta con estar en el lugar y momento correctos; también necesitas no estar ya saturado

Mantenerse con margen

• Si sigues resolviendo trabajo de baja prioridad y te mantienes al 100% de utilización, perderás oportunidades de trabajo de alto impacto de dos formas
• Primero, si estás demasiado ocupado, ni siquiera notarás que la oportunidad existe
  • Tendrás menos tiempo para hablar con personas que están trabajando en otras cosas, leer actualizaciones del equipo o revisar incidentes en curso
  • La mejor forma de participar en trabajo de alto impacto es ofrecer voluntariamente tu experiencia
• Segundo, si siempre pareces ocupado, a tu manager le costará más sumarte
  • La segunda mejor vía de participación es que tu manager o el product manager te conecten porque consideran que “tienes margen para ayudar aquí”
  • Los managers y product managers suelen entender mejor qué trabajo de alto impacto está ocurriendo porque participan en reuniones a las que los ingenieros no asisten

No hacer nada

• Si necesitas liberar tiempo para trabajo de alto impacto y no puedes seguir simplemente procesando tickets, entonces, minuto a minuto, está bien no hacer literalmente nada
• La ingeniería de software puede ser una profesión estresante, pero normalmente no es una profesión de estrés constante
  • El estrés aparece en situaciones como incidentes ocasionales, trabajo urgente de alta presión o despidos recientes
• Si abordas incluso los periodos de menor presión con la intensidad de una urgencia, cuando llegue una situación realmente exigente ya estarás agotado e irritable
• Incluso en periodos de alta presión, una actitud de no hacer nada puede ayudar
  • Los ingenieros que no están acostumbrados a estar on-call harían bien en no apresurarse y en tomar unas cuantas respiraciones antes de entrar a una llamada o antes de hablar
  • En la respuesta a incidentes, en general, hace falta “pensar con movimientos lentos”
• La mayoría de los incidentes se resuelven solos, y los cambios “quizá ayuden” que se meten con prisa durante un incidente suelen empeorar la situación más de lo que la mejoran
• En general, con solo evitar el pánico ya estarás respondiendo mejor que la mayoría de los ingenieros durante un incidente
• El tiempo de no hacer nada crea espacio para que ocurran cosas
  • Cuando el cerebro tiene oportunidad de descansar, es más probable que aparezcan nuevas ideas
  • Cuando te asignan trabajo importante, puedes concentrarte por completo en ello en vez de llevar al mismo tiempo otras tres cosas en segundo plano
  • Cuando no estás ocupado, simplemente tienes tiempo de observar y absorber información nueva

Decidir intencionalmente no hacer ciertas cosas

• A muchos ingenieros les incomoda ver trabajo que podría hacerse y no hacerlo
• Esta tendencia es un rasgo psicológico que comparten muchos ingenieros de software y, hasta cierto punto, es parte de lo que los hace buenos para este trabajo
• Para crear tiempo de no hacer nada, a veces hay que obligarse deliberadamente a no intervenir

• Evitar el trabajo de pegamento

  • En general, los ingenieros deberían evitar el trabajo de pegamento
  • El trabajo de pegamento incluye lograr que distintas personas hablen entre sí, actualizar documentación de trabajo que uno no lidera o conseguir recursos para resolver deuda técnica
  • Gran parte del trabajo de pegamento refleja que la organización no priorizó explícitamente ese trabajo
  • Si la organización sí lo priorizara, no haría falta que una persona se ofreciera voluntariamente
  • Si está bien que la organización no lo haya priorizado, entonces encargarte de eso es una pérdida de tiempo y puede incluso molestar a tu manager
  • Incluso si es un gran error que la organización no lo haya priorizado, si una persona lo resuelve por su cuenta la empresa evita sufrir las consecuencias de su error y quien paga el costo es la carrera y la salud mental de esa persona
  • Es un mal trato para esa persona, un mal ejemplo para colegas junior y un mal precedente en el que, después del burnout, otra persona termina ocupando el mismo lugar
  • Si las consecuencias realmente son graves, hay que dejar que ocurran para que la organización sienta el dolor y cambie sus políticas

• Ayudar demasiado te vuelve vulnerable

  • Intentar ser demasiado servicial te vuelve vulnerable frente a personas que buscan extraer trabajo no recompensado
  • En las empresas tecnológicas hay muchas personas que intentan sacar trabajo de los ingenieros de software sin que eso sea recompensado
  • Es distinto del trabajo que entra por los canales normales y se recompensa con promociones, bonos o salario regular
  • El trabajo problemático entra por canales informales y viene de personas que no pueden o no quieren registrar oficialmente ese trabajo a tu nombre
  • Un ejemplo sería un product manager de otra organización que te pide sacar ciertas métricas porque eres bueno haciendo consultas de datos
  • Otro ejemplo sería un ingeniero de otro equipo que te pide hacer pairing, pero en la práctica logra que tú escribas todo el código y luego presenta el cambio a su nombre
  • Está bien hacer este tipo de trabajo hasta cierto punto, y puedes ayudar a la gente cuando sea posible
  • Pero necesitas ser capaz de ejercer presión de regreso, ya sea rechazando la solicitud o respondiendo con unas horas o unos días de demora

• No sobreinvertir en trabajo que probablemente desaparezca

  • Conviene no invertir demasiado en trabajo que probablemente vaya a desaparecer
  • Si estás acomodando en tiempo real lo que quiere un diseñador de producto, no deberías reescribir por completo una página cada hora
  • Un ejemplo sería querer el header de una página de una forma a las 9 a. m., cambiarlo a las 10 y volver a cambiarlo a las 11
  • En estos casos, es mejor no hacer nada —por ejemplo, salir a caminar— y luego reescribir una sola vez por la tarde según el diseño más reciente
  • Otra situación común es la gran idea de un manager que no tiene suficiente impulso político
  • Muchas veces solo hace falta dejar pasar el tiempo hasta que cancelen el proyecto
  • Sin embargo, si juzgas mal el nivel de apoyo político del proyecto, puedes parecer flojo y terminar en una situación donde debas entregar resultados con urgencia

Conclusión

• Los consejos y herramientas de ingeniería de software suelen enfocarse en la capacidad de escalar el esfuerzo técnico para hacer más trabajo al mismo tiempo, asumir proyectos de mayor alcance y escribir más código
• El éxito en ingeniería de software no se decide por esos factores
• El éxito depende de la capacidad de hacer lo correcto en el momento correcto, y para eso hace falta reservar deliberadamente parte del esfuerzo en el trabajo cotidiano
• Es posible convertirse en un ingeniero de alto rendimiento con un 80% de esfuerzo; de hecho, eso reduce errores tontos causados por el estrés y hace más fácil lanzarse sobre trabajo de alto impacto que genera grandes beneficios
• También hay momentos en los que sí hace falta comprometerse al 100%; unas dos o tres veces al año puede tocar trabajar durante mucho tiempo, con concentración intensa y pensando en el problema todo el día
• Conviene reservar esa forma de trabajar para cuando la recompensa realmente sea grande, y durante el resto del tiempo trabajar con relativa holgura

[GN⁺]

Comentarios de Hacker News

• Es un buen texto, pero al final otra vez queda claro que el problema son los incentivos
  Es cierto que prevenir o mitigar un incidente temprano puede ahorrar mucho dinero, pero lo que he visto una y otra vez en varias empresas es que la prevención de problemas no recibe reconocimiento, mientras que si apilas mucho material inflamable y luego apagas el incendio inevitable, te reconocen dos veces. Incluso pasó en organizaciones “buenas”
  Nunca logré meterme de lleno en esa política con lógica de teoría de juegos de sacar rápido código basura y luego llevarse el crédito. Me importaba demasiado sentir orgullo por mi trabajo
  Durante más de 5 años mantuve y expandí un framework para eliminar una familia de problemas que atormentaba a la versión anterior del producto, pero un equipo asociado que desplegó código basura, provocó incidentes y luego los arregló recibió elogios públicamente, mientras que nuestro equipo no obtuvo ningún mérito porque no hubo incidentes así. Porque es prevención imposible de medir

  • En términos de teoría de juegos, un equipo que repetidamente causa problemas y pierde clientes debería ser castigado en consecuencia. Si no es así, quizá los problemas que surgen por desplegar rápido no afectan la retención de clientes tanto como uno pensaría
  • Solo hay que poner Thread.sleep(100000) por todas partes y esperar a que algo se rompa. Entonces te conviertes en la persona que hizo una larga y heroica apaga-incendios hasta la medianoche del viernes después del release
    Mejor no preguntes por qué eso se recompensa, y claro, a veces la organización cambia también sus criterios de recompensa
  • Sobre eso de que “no te reconocen por no haber tenido esos incidentes porque no se puede medir”, filosóficamente yo diría que incluso se puede medir el peso de la nada
  • Tristemente, eso es totalmente cierto, pero no es la única forma
    Un enfoque honesto es construir algunas herramientas complejas pero esenciales para que otros ingenieros sigan viniendo a buscarte. Terminas volviéndote muy bueno detectando el mal uso de cierta herramienta, y si puedes señalar bugs en código ajeno en segundos, pareces mucho más inteligente de lo que realmente eres
    Idealmente, la herramienta debe ser confiable y útil, pero compleja. Cuando otros desarrolladores la usan y se topan con un bug, siguen regresando a ti, y tú puedes señalar sus errores. Para que esta estrategia funcione, los errores casi siempre tienen que estar del lado de ellos, y tu código debe ser robusto
    Si encuentran un bug real en tu código, de ser posible algún caso límite pequeño, tienes que ser muy humilde y disculparte, y en la reunión del equipo debes elogiar al desarrollador que encontró ese bug complicado
    Es mejor que obtener reconocimiento arreglando tu propio código defectuoso. Eso puede funcionar con managers o juniors, pero a otros ingenieros senior no les va a gustar
    El método de crear herramientas complejas pero estables hace que te reconozcan repetidamente, muchas veces bastante más de dos, y el reconocimiento de otros desarrolladores eventualmente también llega a oídos de los managers. Los líderes inteligentes saben que esta señal vale más que una demo vistosa
    Los líderes que reparten elogios solo porque cierto desarrollador hace prototipos rápido terminan aprendiendo la lección. Los fundadores jóvenes parecen pasar seguido por esa etapa de elogiar lo superficial
  • Si lo planteas como una oposición así, estoy de acuerdo, pero hace falta algo de matiz
    Parte del trabajo de crear un producto o un paquete de funcionalidades se parece más a la exploración que a una gran labor de ingeniería. A veces es mejor hacer dos funcionalidades suficientemente buenas para descubrir qué tiene valor para los usuarios, en vez de hacer una sola funcionalidad sólida
    Yo siempre he sido más de “probemos y veamos”. Dicho eso, agradezco que alguien con una actitud distinta a la mía haya creado git
    Aquí hay un equilibrio, y depende de qué tanto el problema que estás tratando sea uno de exploración. Aquí “solidez” significa cosas como disponibilidad, mantenibilidad o la posibilidad de filtrar fotos sensibles de usuarios desde una perspectiva puramente de ingeniería

• La parte sobre “personas que quieren exprimirte trabajo sin recompensa” merece estar enmarcada
  Especialmente situaciones como cuando un product manager de otra organización te dice “como eres bueno haciendo consultas de datos, ¿me podrías sacar unas estadísticas sobre X?”, o cuando un ingeniero de otro equipo pide hacer “pair” y al final yo termino escribiendo todo el código y esa persona mete el cambio discretamente a su nombre

  • Donde trabajo, Principal Engineer es un título que todos quieren, está muy bien remunerado, pero al que rara vez se llega. Todas las personas con las que he trabajado que lo tenían eran muy capaces y además agradables, y una vez le pregunté a una de ellas cómo había conseguido ese título en su empresa anterior
    Su estrategia era ayudar a la gente y cederles el crédito activamente. En reuniones 1:1 o en reuniones con varios niveles de management, destacaba de forma constante el valor del trabajo de los miembros de su equipo, y gracias a eso se ganó la buena voluntad del equipo
    Años después, cuando un proyecto con mucho dinero en juego se retrasó y varios ingenieros clave renunciaron, él trabajó horas extra y llevó el proyecto al éxito, y en la evaluación siguiente recibió el título y un aumento salarial
    Ese proyecto sí fue el empujón final, pero no fue el único ingeniero que trabajó horas extra. Él ve su ascenso como resultado de la buena voluntad acumulada al dar crédito a otros durante todo su tiempo en la empresa
  • Creo que esto depende de qué tan involucrado esté tu jefe. Uno de los tipos de personas con las que no quiero trabajar es el que dice “eso no está en mi trabajo”
    Quiero trabajar con personas que ven un problema y proponen una solución, esté o no en la descripción del puesto
    Si mi trabajo no recibe reconocimiento, entonces eso es un problema de liderazgo. Rechazar las cosas de manera tajante se siente como el camino hacia una cultura organizacional rígida y lenta
  • La frase para enmarcar es “por favor conviértelo en un ticket”
  • Es cierto, pero no lo veo de una forma tan blanco y negro. Más allá de cuidar directamente mi propia compensación, también hay incentivos para ayudar a que la empresa tenga éxito, así que aunque no te hagan un desfile, puede ser razonable ayudar con una petición pequeña
    Del mismo modo, algún día yo también podría necesitar algo de un colega, y en ese momento agradecería que me ayudara activamente en lugar de mandarme de vuelta al “canal formal”. El canal formal puede tardar mucho más
  • Las buenas empresas tienen cultura, y la gente se ayuda entre sí
    Las conversaciones en el almuerzo ayudan a que la gente entienda cosas
    Aun así, hacer un trabajo de varias horas para alguien puede ser otro tema por completo

• No es sarcasmo, más bien una observación, pero en organizaciones lo bastante grandes o burocráticas es difícil obtener mérito o visibilidad por prevenir problemas de antemano. Ese tipo de logros se mete en la categoría de “era lo que se suponía que había que hacer”.
  Por eso la gente hábil para la política de oficina prefiere dejar que ocurra el incidente y luego moverse de forma aparatosa en los puntos de seguimiento. El truco está en no dejar que el incidente se convierta en un desastre, y eso requiere bastante delicadeza.

  • Lo aprendí pronto en una organización conservadora. La prevención es riesgosa. Es mejor tener lista la solución para cuando algo salga mal, porque solo entonces se consigue la aprobación.
  • Todos los ejemplos de gran impacto parecen ser trabajos difíciles de reconocer.
    Si salvas un contrato de ventas, los aplausos se los lleva el equipo comercial, y la comisión también. Yo no recibo ni una parte de eso.
  • Un desastre también puede ser una buena señal para niveles superiores de que hay un problema en la organización. Si apagas heroicamente todos los incendios, tal vez tu jefe lo note, pero el jefe de tu jefe de tu jefe ve una organización que funciona de maravilla y todo en verde.
    Si dejas que algunas cosas se quemen, el jefe de tu jefe de tu jefe verá ese fuego y quizá haya mejoras. Tal vez sea la forma más fácil de comunicarse con ellos.
  • La clave es si la gente se da cuenta. He oído que en gobiernos locales a veces recortan programas populares para provocar rechazo y luego se llevan el mérito por restaurarlos. En medio de eso también pueden colar otras medidas necesarias pero impopulares.
  • Muchas veces las carreras y los bonos se construyen a partir de jugar al héroe.

• Hace tiempo tenía medio escrito algo en esta línea, usando una analogía de RPG de fantasía. Cuando juegas con un personaje que usa maná en uno de esos juegos, aprendes rápido que si gastas todo el maná en cada combate menor, luego andas vacío y no te queda nada cuando de verdad lo necesitas.
  La energía mental que usas en el trabajo no es tan distinta. Si dejas un poco en el tanque, puedes usarla estratégicamente cuando surja algo inesperado sin poner en riesgo tu salud, o sea, el burnout.
  Si alguna vez formas grupo con un jugador que no sabe administrar su maná en esos juegos, también aprendes que no es precisamente un gran compañero de equipo.

  • Sentí que, si durante un tiempo no te desafían lo suficiente, luego puede volverse extremadamente difícil superar el siguiente desafío.
    En cualquier área, los momentos en que mis capacidades estaban en su punto máximo fueron aquellos en que tenía suficiente trabajo por delante como para procesarlo de forma constante, casi mecánica, y me tenían la confianza suficiente para trabajar hacia un objetivo sin interrupciones ni tener que detenerme a explicarlo todo. Las habilidades crecían como fuego descontrolado y el trabajo terminaba antes de lo esperado.
    Por desgracia, son muy pocos los trabajos que aprovechan una estructura así. Hay demasiados bloqueos e interrupciones que impiden entrar en verdadero trabajo profundo.
  • En mi caso, terminaría el RPG con 29 ethers todavía en el inventario, aunque usar algunos al principio habría hecho el farmeo mucho menos pesado.

• Si quieres romper un sistema, haz que opere al 100% de su capacidad. Como no queda margen ni capacidad para absorber demanda nueva, basta una pequeña perturbación para que el sistema entre en modo de falla permanente.

  • La eficiencia es enemiga de la resiliencia.
  • Pero el colapso no ocurre. Cuando los ingenieros se queman o envejecen, simplemente contratan gente nueva y el ciclo se repite.
    El problema con textos como este o con libros como Peopleware / Slack es que no presentan métricas reales lo bastante convincentes como para que la gente de finanzas pruebe otro enfoque.

• La analogía que me cambió la perspectiva venía de “The Power of Full Engagement”. Era algo como: “Te estás comportando como un atleta de resistencia de clase mundial sin temporada baja. Déjalo”.

• Aquí hay mucha sabiduría. Además de dejar parte de la capacidad libre para cuando llegue algo de verdadero valor, creo que la ingeniería de software no es algo que se haga bien estando ocupado todo el tiempo.
  Si intentas escribir código lo más rápido posible, rara vez sale un buen diseño. Este texto tampoco toca otro aspecto importante: cómo trabajar al 80% de capacidad sin que te regañe tu gerente.
  Para eso hace falta algo de cuidado en la comunicación y en la estimación del trabajo. Uno de los mejores consejos que recibí de desarrolladores veteranos en mi primer trabajo real programando todavía me acompaña: estima cuánto tardará algo y, antes de decírselo al gerente o al usuario, duplícalo.
  Con la experiencia ese factor quizá baje de 2x a algo como 1.5x, pero el principio sigue aplicando.

  • Kent Beck dijo, ya fuera en Good News Factory o en una charla, que su equipo nunca comprometía más de la mitad de lo que creía que podía hacer. Es una buena forma de sostenerse en el tiempo.
    Lo que hay que optimizar y tomar como referencia es entregar de forma constante y a ritmo sostenible a largo plazo. Esto es un juego largo, y prometer de más solo desgasta la confianza. Esa confianza es justamente la mayor herramienta que tiene un desarrollador para conseguir el espacio que necesita.
    Hay que prometer menos, construir reputación de cumplir lo que se dice y ganar espacio para no quemarse.
    Cuanto más senior eres, y más aún si eres líder, más parte del trabajo se vuelve poner límites, conservar la atención y evitar el burnout. Hay demasiadas formas de romperte a ti mismo.
  • Eso de “duplica tu estimación antes de decírsela al gerente o al usuario” suena bien, pero me pregunto si toma en cuenta la ley de Hofstadter.
    Incluso teniendo en cuenta la ley de Hofstadter, las cosas siempre tardan más de lo esperado.
    https://en.wikipedia.org/wiki/Hofstadter%27s_law

• Habiendo hecho mucho trabajo de cara al cliente, la peor trampa con la que me topé varias veces fue hacerme amigo del cliente que paga. Desde la posición de alguien contratado como experto para ayudar, cuando el cliente resulta ser realmente buena persona, se vuelve absurdamente difícil decir que no.
  Y es peor todavía cuando esa persona no es quien toma las decisiones, sino alguien a quien presionan para que me imponga cosas. Como experto de confianza, es fácil rechazarlo cuando el propio cliente propone una mala idea, pero si la orden viene de su jefe, a quien nunca trato directamente, termino quedando como un costo inútil o como un sí señor que deja atrás un monstruo.
  A veces envidio a la gente que ha trabajado principalmente en roles internos. Al menos ellos podían intentar convencer a alguien de más arriba.

• La parte sobre el trabajo pegamento me parece interesante; cuando trabajaba en una gran empresa, esto era una parte explícita de la evaluación anual de desempeño. Google lo llamaba “citizenship”, y me parece un término que captaba bien la esencia. Básicamente era: “¿qué hiciste para mejorar las cosas para el resto de la empresa?”
  Por un lado, se sentía un poco raro. No estaba en la descripción de mi puesto, así que técnicamente era trabajo no remunerado, pero al mismo tiempo era parte de las expectativas oficiales. Por otro lado, me gustaba trabajar en un lugar donde todos invertían un poco de tiempo y esfuerzo para mejorar el entorno para todos
  Si lo conviertes en un requisito explícito para todos, también es una forma de esquivar la cultura tóxica de “soy un ingeniero estrella y estoy demasiado ocupado con cosas importantes, que alguien más haga el trabajo pegamento”. Además, ese “alguien más” solía ser una mujer y casi seguro ganaba menos que ese ingeniero estrella
  El texto original sugiere que la empresa debería contratar formalmente a alguien para hacer el trabajo pegamento, pero en la práctica está compuesto de demasiadas piezas distintas, así que es casi imposible contratar a una sola persona para encargarse de todo. Por ejemplo, ¿qué título abarcaría “redacción de documentación, entrevistas para ingenieros de software y organización de retiros del equipo”?
  Pero todas esas tareas eran necesarias, y el requisito de citizenship ayudaba a repartir la carga de manera más justa
  Creo que una mejor forma de decirlo no es “no hagas trabajo pegamento”, sino “no seas el único tonto que hace trabajo pegamento sin compensación”. O sea, hay que impulsar una cultura donde todos se hagan cargo de una parte y eso se reconozca oficialmente como trabajo

• Operar con 80% de utilización es un buen hábito, y ayuda cuando no tienes a un gerente estilo capataz exigiendo 100% todos los días, todo el día. Esa clase de gente malinterpreta a un ingeniero de software callado y tranquilo pensando cómodamente como si fuera flojera o inactividad
  Por eso el trabajo remoto es la mejor forma de dejar algo de utilización en reserva y cuidar la salud mental
  Un poco de trabajo pegamento puede hacer muchísimo mejor la vida laboral de todos y, si nadie más sabe cómo hacerlo, puede convertirte en una persona indispensable o en el héroe del equipo

  • Yo diría que 80% sigue siendo alto. Y además depende de cada desarrollador
    Considerando lo mucho que me cuesta aprender, pensar y arrancar, mi 80% no se parece en nada al 80% de un colega técnicamente más fuerte
    Si consideras aunque sea un poco la neurodiversidad, el 80 de una persona puede ser el 120 de otra