- Los ingenieros sobresalientes no son los mejores programadores, sino quienes han aprendido a navegar a las personas, la política, la coordinación y la ambigüedad alrededor del código
- Se enfoca menos en la tecnología y más en los patrones que aparecen repetidamente en proyectos y equipos, cubriendo resolución de problemas de usuarios, colaboración en equipo, calidad del código y gestión de carrera
- Muestra la idea de que la claridad es la cualidad central de un ingeniero senior y que la brillantez es solo overhead, junto con la intuición paradójica de que el mejor código es el que no se escribió
- En organizaciones grandes, el fracaso de alineación es una causa principal de la pérdida de velocidad, y revela la trampa organizacional de que cuando una métrica se convierte en objetivo, se distorsiona
- A largo plazo, el tiempo se vuelve un recurso más valioso que el dinero, y como la red de contactos dura más que cualquier empleo, hace falta diseñar la carrera de forma intencional
1. Los mejores ingenieros se obsesionan con resolver problemas de los usuarios
- Es tentador enamorarse primero de una tecnología y luego buscar dónde aplicarla, pero los ingenieros que crean más valor trabajan al revés: entienden profundamente el problema del usuario y a partir de ahí derivan la solución
- La obsesión por el usuario significa invertir tiempo en tickets de soporte, hablar con usuarios, observar sus dificultades y preguntar "por qué" hasta llegar a la raíz
- Los ingenieros que realmente entienden el problema a menudo descubren que la solución elegante es más simple de lo esperado
- Los ingenieros que empiezan por la solución tienden a construir complejidad para encontrar cómo justificarla
2. Tener razón es fácil; llegar juntos a lo correcto es el verdadero trabajo
- Puedes ganar cada debate técnico y aun así perder el proyecto, y he visto ingenieros brillantes que siempre eran la persona más inteligente del cuarto mientras acumulaban resentimiento silencioso
- El costo aparece después como "problemas misteriosos de ejecución" y "resistencia extraña"
- La habilidad central no es tener razón, sino participar en la discusión para alinear el problema, crear espacio para otros y mantener una actitud escéptica frente a la propia certeza
- Opiniones fuertes, apego débil: no por falta de convicción, sino porque las decisiones bajo incertidumbre no deben fusionarse con tu identidad
3. Lanza con sesgo a la acción. Una página mala se puede editar, una página vacía no
- La búsqueda de perfección causa parálisis, y he visto ingenieros pasar semanas debatiendo la arquitectura ideal de algo que nunca han construido
- La solución perfecta no surge solo del pensamiento, sino del contacto con la realidad, y la IA puede ayudar de muchas maneras
- Primero hacerlo, luego hacerlo bien y después hacerlo mejor: poner un prototipo feo frente a los usuarios, redactar un borrador desordenado de diseño y lanzar un MVP un poco vergonzoso
- Se aprende más de una semana de feedback real que de un mes de debate teórico; el impulso crea claridad y la parálisis por análisis no construye nada
4. La claridad es la marca del seniority, y la brillantez es overhead
- El impulso de escribir código brillante es casi universal entre ingenieros y se siente como una prueba de capacidad
- La ingeniería de software ocurre cuando agregas tiempo y otros programadores, y en ese entorno la claridad no es una preferencia de estilo sino reducción de riesgo operativo
- El código es una nota estratégica para personas desconocidas que lo mantendrán a las 2 a. m. durante una caída, así que no debe optimizarse para la elegancia sino para su comprensión
- Los ingenieros senior más respetados aprenden a cambiar brillantez por claridad, siempre
5. La novedad es una deuda que pagas con incidentes, contratación y overhead cognitivo
- Trata las decisiones tecnológicas como si la organización tuviera un pequeño presupuesto de "tokens de innovación", y consume uno cada vez que adoptas algo realmente no estándar; no puedes sostener muchos
- El punto no es "nunca innoves", sino "innova solo donde te recompensan por innovar de forma única"; en todo lo demás, lo aburrido debería ser lo predeterminado
- Eso es porque lo aburrido tiene modos de falla conocidos
- La "mejor herramienta para el trabajo" a menudo significa "la herramienta menos mala para muchos trabajos", porque operar un zoológico de tecnologías tiene un costo real
6. El código no habla por ti; la gente sí
- Al inicio de mi carrera creía que un gran trabajo hablaría por sí solo, pero eso era un error; el código solo se queda quieto en el repositorio
- Un manager te menciona o no en una reunión, y un colega te recomienda para un proyecto o recomienda a otra persona
- En organizaciones grandes, las decisiones las toman personas con 5 minutos y 12 prioridades, en reuniones a las que no fuiste, a partir de resúmenes que no escribiste directamente
- Si nadie puede expresar tu impacto en la sala donde no estás, ese impacto en la práctica es opcional; no se trata de autopromoción, sino de hacer legible la cadena de valor para todos, incluyéndote a ti
7. El mejor código es el que no hacía falta escribir
- La cultura de ingeniería celebra crear, pero muchas veces eliminar mejora más un sistema que agregar, aunque nadie asciende por borrar código
- Cada línea de código no escrita es una línea que no habrá que depurar, mantener ni explicar
- Antes de construir, hay que agotar la pregunta: "¿y si simplemente... no lo hacemos?" A veces la respuesta es "no pasa nada malo", y esa es la solución
- El problema no es que los ingenieros no puedan escribir código o no puedan escribirlo con IA, sino que lo escriben tan bien que olvidan preguntar si realmente había que escribirlo
8. A escala, hasta los bugs retienen usuarios
- Cuando tienes suficientes usuarios, todo comportamiento observable se vuelve una dependencia, sin importar lo que prometiste; alguien hace scraping del API, automatiza rarezas y cachea bugs
- Eso lleva a una intuición de nivel carrera: no puedes tratar el trabajo de compatibilidad como "mantenimiento" y las nuevas funciones como "trabajo real", porque la compatibilidad es producto
- Hay que diseñar la deprecación como migración, con tiempo, herramientas y empatía
- La mayor parte del "diseño de APIs" en realidad significa "retiro de APIs"
9. La mayoría de los equipos "lentos" en realidad están desalineados
- Cuando un proyecto se retrasa, el instinto es culpar a la ejecución —la gente no trabaja lo suficiente, la tecnología está mal, faltan ingenieros—, pero normalmente ese no es el problema real
- En una empresa grande, los equipos son la unidad de concurrencia, pero mientras más se multiplican, el costo de coordinación crece de forma exponencial
- La mayor parte de la lentitud en realidad significa fracaso de alineación: construir lo incorrecto o construir lo correcto de manera incompatible
- Los ingenieros senior invierten más tiempo en aclarar dirección, interfaces y prioridades que en "escribir código más rápido", porque ahí está el cuello de botella real
10. Enfócate en lo que puedes controlar e ignora lo imposible
- En las empresas grandes hay muchísimas variables fuera de tu control —cambios organizacionales, decisiones de management, movimientos del mercado, giros de producto— y obsesionarte con eso crea ansiedad sin agencia
- Los ingenieros que se mantienen cuerdos y son efectivos se concentran en su esfera de influencia: no puedes controlar si habrá una reorganización, pero sí la calidad de tu trabajo, cómo respondes y qué aprendes
- Frente a la incertidumbre, hay que dividir el problema en partes e identificar acciones concretas que sí están a tu alcance
- No es aceptación pasiva, sino enfoque estratégico; la energía que gastas en lo que no puedes cambiar es energía que le robas a lo que sí puedes cambiar
11. La abstracción no elimina la complejidad; la mueve al momento en que tú estás on-call
- Toda abstracción es una apuesta a que no necesitarás entender lo que hay debajo, y a veces esa apuesta sale bien
- Pero algo siempre se filtra, y cuando eso pasa necesitas saber sobre qué estás parado
- Los ingenieros senior siguen aprendiendo cosas "de nivel inferior" a medida que el stack crece, no por nostalgia sino por respeto a esos momentos en que la abstracción falla y te quedas a solas con el sistema a las 3 a. m.
- Usa el stack, pero mantén un modelo mental operativo de sus modos básicos de falla
12. Escribir fuerza claridad. La forma más rápida de aprender mejor algo es intentar enseñarlo
- Escribir fuerza claridad, y cuando explicas un concepto a otros —en documentación, presentaciones, comentarios de code review o incluso chateando con IA— descubres huecos en tu comprensión
- El acto de hacer algo legible para otros también lo vuelve más legible para ti
- Esto no significa que aprendas a ser cirujano enseñando a ser cirujano, pero la premisa es bastante cierta en el ámbito de la ingeniería de software
- No solo es generosidad al compartir conocimiento, también es un hack egoísta de aprendizaje: si crees que entiendes algo, intenta explicarlo de forma simple; donde te trabes, ahí tu comprensión es superficial
- Enseñar es depurar tus propios modelos mentales
13. El trabajo que hace posible el trabajo de otros es valioso, pero invisible
- El trabajo pegamento —documentación, onboarding, coordinación entre equipos, mejoras de proceso— es esencial, pero si lo haces de forma inconsciente puede estancar tu trayectoria técnica y llevarte al burnout
- La trampa es tratarlo como algo simplemente "útil" en lugar de manejarlo con intención, límites e impacto visible
- Hay que ponerle límites de tiempo, rotarlo y convertirlo en entregables: documentos, plantillas, automatización; y volverlo legible como impacto, no como rasgo de personalidad
- Ser valioso pero invisible es una combinación peligrosa para la carrera
14. Si ganas todas las discusiones, probablemente estás acumulando resistencia silenciosa
- Aprendí a dudar de mis propias certezas, y cuando "ganas" demasiado fácil, normalmente algo está mal
- La razón por la que la gente deja de discutir contigo no es que la convenciste, sino que se rindió, y luego expresa ese desacuerdo en la ejecución, no en la reunión
- La alineación real toma más tiempo: entender de verdad otras perspectivas, integrar feedback y, a veces, cambiar de opinión en público
- La satisfacción de corto plazo de tener razón vale mucho menos que la realidad de largo plazo de construir algo con colegas dispuestos a colaborar
15. Cuando la medición se convierte en objetivo, deja de medir
- Toda métrica expuesta al management termina siendo manipulada, no por malicia sino porque las personas optimizan lo que se mide
- Si rastreas líneas de código, obtendrás más líneas; si rastreas velocidad, obtendrás estimaciones infladas
- El movimiento senior es responder a cada pedido de métricas en pares: una para velocidad y otra para calidad o riesgo; luego insistir en interpretar tendencias en lugar de adorar umbrales
- El objetivo es insight, no vigilancia
16. Admitir lo que no sabes genera más seguridad que fingir que sabes
- Un ingeniero senior que dice "no sé" no está mostrando debilidad, sino creando permiso
- Cuando un líder admite incertidumbre, le muestra a otros que también pueden hacerlo; la alternativa es una cultura donde todos fingen entender y los problemas se esconden hasta explotar
- He visto equipos donde la persona más senior no admite confusión, y también el daño que eso causa: no aparecen preguntas, no se desafían supuestos y los ingenieros junior guardan silencio porque asumen que todos los demás sí entienden
- Si modelas curiosidad, obtienes un equipo que realmente aprende
17. Tu red de contactos dura más que cualquier trabajo que vayas a tener
- Al principio de mi carrera me enfoqué en el trabajo y descuidé el networking, y viéndolo en retrospectiva, fue un error
- Los colegas que invirtieron en relaciones —dentro y fuera de la empresa— cosechan beneficios durante décadas
- Se enteran antes de las oportunidades, pueden tender puentes más rápido, los recomiendan para roles y cofundan proyectos con personas con las que construyeron confianza durante años
- Los empleos no duran para siempre, pero tu red sí dura más que cada empleo; hay que abordarla con curiosidad y generosidad, no con hustle transaccional
- Cuando llega el momento de irte, muchas veces son las relaciones las que abren puertas
18. La mayoría de las mejoras de rendimiento vienen de quitar trabajo, no de agregar brillantez
- Cuando un sistema se vuelve lento, el instinto es agregar cosas —capas de caché, paralelismo, algoritmos más inteligentes—; a veces eso es correcto, pero he visto más mejoras de rendimiento al preguntar "¿qué es lo que no necesitamos calcular?"
- Eliminar trabajo innecesario casi siempre tiene más impacto que hacer más rápido el trabajo necesario, y el código más rápido es el que no se ejecuta
- Antes de optimizar, hay que cuestionar si ese trabajo necesita existir
19. Los procesos existen para reducir incertidumbre, no para generar trazas en papel
- Los mejores procesos hacen más fácil coordinarse y más barato fallar; los peores son teatro burocrático: existen no para ayudar, sino para asignar culpas cuando algo sale mal
- Si no puedes explicar cómo un proceso reduce riesgo o aumenta claridad, probablemente sea solo overhead
- Si la gente pasa más tiempo documentando el trabajo que haciendo el trabajo, algo está gravemente mal
20. Al final, el tiempo se vuelve más valioso que el dinero, así que actúa en consecuencia
- Al inicio de la carrera cambias tiempo por dinero, y está bien, pero en algún momento la cuenta se invierte: empiezas a darte cuenta de que el tiempo es un recurso no renovable
- He visto ingenieros senior quemarse persiguiendo el siguiente nivel de ascenso y optimizando unos cuantos puntos porcentuales extra de compensación
- Algunos lo consiguieron, pero la mayoría después se preguntó si realmente valía la pena lo que sacrificaron
- La respuesta no es "no trabajes duro", sino "sé consciente de lo que estás intercambiando y hazlo de forma intencional"
21. No hay atajos, pero sí interés compuesto
- La maestría viene de la práctica deliberada: empujarte un poco más allá de tus habilidades actuales, reflexionar y repetirlo durante años; no hay versión comprimida
- La parte esperanzadora es que aprender funciona con interés compuesto cuando crea nuevas opciones, no solo pequeñas piezas de conocimiento nuevas
- Escribe, pero no por engagement sino por claridad; construye piezas reutilizables y convierte el tejido cicatricial en playbooks
- Los ingenieros que tratan su carrera como interés compuesto tienden a quedarse muy por delante de quienes la tratan como un boleto de lotería
Reflexión final
- 21 lecciones parecen muchas, pero en realidad se reducen a unas pocas ideas centrales: mantén la curiosidad, mantén la humildad y recuerda que el trabajo siempre trata de personas: los usuarios para quienes construyes y los compañeros con quienes construyes
- Una carrera en ingeniería es lo bastante larga como para cometer muchos errores y aun así seguir adelante, y los ingenieros que más respeto no son quienes hicieron todo bien, sino quienes aprendieron de lo que salió mal, compartieron lo que descubrieron y siguieron apareciendo
- Si estás al inicio del camino, recuerda que esto se enriquece con el tiempo; si ya tienes profundidad, espero que algo de esto te resuene
5 comentarios
Comentarios de Hacker News
Me hizo pensar en la frase: "cuando algo escala, hasta los bugs consiguen usuarios"
En mi primer trabajo, cuando redujimos el tiempo de carga de 5 minutos a 30 segundos, los clientes se quejaron
porque ya no tenían ese rato para dejar la computadora prendida, ir por café y platicar
La lección de esta historia no es simplemente que no debas mejorar las cosas, sino que el software existe dentro de los hábitos e interacciones de personas reales
El trabajo de un ingeniero no es cerrar tickets, sino resolver problemas reales de los usuarios
Mientras más subía la eficiencia, más trabajo físico tenían que hacer los empleados, así que terminaron molestos
Al final, yo quedé como el que “arruinó un buen sistema”
Dice: “con una cantidad suficiente de usuarios, todo comportamiento observable de un sistema termina siendo una dependencia para alguien”
Cada vez pensaba “ahora sí lo van a arreglar”, pero nunca lo corrigieron en 10 años, y de hecho eso mantuvo vivo el negocio
Los tres entienden el problema de manera distinta
El significado del código no cambia por intención o esperanza, y solo funciona dentro de las restricciones del mundo real
Texto relacionado: Laws of Software Evolution
Pero no todas las empresas piensan así
Es importante dejar claras las expectativas en la entrevista
Al leer el texto de Addy Osmani sentí un poco de hipocresía
Hace tiempo plagió mi código, y luego publicó una disculpa, pero no la compartió en redes sociales
Si la disculpa era sincera, creo que también debió hacerla pública para sus seguidores
Las primeras tres lecciones me pegaron especialmente
El problema es que en la formación se enseñan lenguajes y frameworks, pero no el problema en sí
El consenso se construye dentro del proceso creativo, y el poder debería usarse en tiempos de crisis
Muchas veces se desperdicia tiempo discutiendo por miedo a fracasar
En el ensayo "Boring Technology" fue donde conocí por primera vez el concepto de “innovation tokens”
Es un texto de boringtechnology.club, y sigue siendo uno de mis artículos favoritos sobre arquitectura
La frase “la abstracción no elimina la complejidad, solo la mueve al momento en que tú estás on-call” me recuerda la Law of Leaky Abstractions de Joel Spolsky
Durante 15 años en liderazgo operé sistemas de miles de millones de dólares en una gran empresa de retail
Pero al final, lo que realmente importaba era la política y las relaciones humanas
Gente más inteligente no ascendía simplemente por no saber manejar la política
La conclusión amarga es que habría que enseñarles a los hijos “política y adulación”
Me identifiqué mucho con la frase "Clarity is seniority"
La claridad es clave para la mantenibilidad y la escalabilidad
Escribí un libro para enseñar eso: Elements of Code
La abstracción no es mala en sí; el problema es la claridad del propósito
Es como un ingeniero civil construyendo un puente dentro de una bodega sin ver el terreno
No hay que culpar a la abstracción en sí, sino entender qué se está intentando modelar
Una mala abstracción daña la claridad y crea complejidad innecesaria
Personalmente, creo que es mejor que falte abstracción a que sobre
El verdadero valor de estas listas está en escribir la tuya
Solo leerlas hace que se olviden rápido; tienen sentido cuando tú mismo reflexionas sobre tu carrera y las ordenas
Este texto no trata de los valores oficiales de Google, sino de lecciones personales aprendidas trabajando en Google
No fueron cosas enseñadas por la organización, sino descubrimientos propios a partir de la experiencia
El punto es que incluso en una empresa grande siguen siendo temas difíciles
La idea de que “cuando algo escala, hasta los bugs consiguen usuarios” se parece al fenómeno de ossification (rigidez)
No solo aplica a protocolos de red, sino a cualquier sistema
La razón de diseño criptográfico detrás de HTTP/3 y QUIC también es impedir que los dispositivos intermedios hagan suposiciones equivocadas
Lo mismo pasa con las API: no deberían exponer su estado interno
La frase "Bias towards action" me pareció muy buena
Ningún consejo, por bueno que sea, sirve frente a una página en blanco
Primero hay que hacer algo para poder recibir retroalimentación
En cuanto escribes la primera letra, empiezan a aparecer problemas inesperados
Mientras más grande es la organización, más cuellos de botella invisibles hay de este tipo
“Ship fast” no significa “sácalo todo mal hecho”
Creo que un producto mínimo viable bien terminado suele ser mejor
Hay una gran distancia entre el ideal y la realidad, y el autor lo ironiza diciendo que “el Kool Aid estaba rico”
Si no, se interpreta como trabajo improvisado y, cuando algo sale mal, terminas siendo el chivo expiatorio
Buen texto. Fue una oportunidad para recordar de nuevo la idea de que el crecimiento profesional incluye la madurez personal. Lo leí muy a gusto.
Son puras verdades, de principio a fin.
La lección número 1 ya es importantísima.
Últimamente lo estoy sintiendo muchísimo jaja
Hay tantísimo contenido bueno y tantas frases llenas de perspectiva que me hizo soltar exclamaciones de admiración. También me gustó más porque marcó en negritas las frases principales.
"Tener razón vale mucho menos que la realidad de largo plazo de construir algo junto con colegas dispuestos a colaborar."
"Hay que ejercer un enfoque estratégico, y la energía que se gasta en lo que no se puede cambiar es energía que se le roba a lo que sí se puede cambiar."
No solo había ideas aplicables al trabajo, también muchas que sirven para la vida. Gracias por el buen texto.
"El código es una nota estratégica para personas desconocidas que tendrán que darle mantenimiento a las 2 a. m. durante una caída, así que debe poder optimizarse para la comprensión."
"El impulso crea claridad, y la parálisis por análisis no construye nada."