Escribir código no es difícil, la dificultad radica en tratar con «personas» y «complejidad». Un ingeniero senior de Google comparte 14 años de experiencia, desde el pensamiento centrado en el usuario hasta la colaboración en equipo, estas 21 reglas de oro te ayudarán a lograr una carrera más profunda y duradera.
（Resumen previo: Google Traducción en tiempo real abre oficialmente todas las marcas de auriculares: más de 70 idiomas en línea, lanzamiento en teléfonos Android de EE. UU., México e India）
（Información adicional: ¡Google lanza oficialmente «Gemini 3»! ¿Qué puntos destacados tiene?）

Índice de este artículo

• 1. Los ingenieros de élite están obsesionados con resolver problemas de los usuarios
• 2. «Probar que uno tiene razón» no tiene valor, lo importante es alcanzar objetivos correctos en conjunto
• 3. Enfócate en la acción. ¡Lanza! Puedes modificar páginas malas, pero no páginas en blanco
• 4. La experiencia se refleja en la claridad, la inteligencia en la carga
• 5. «Novedad» es un préstamo de alto interés a mantenimiento, reclutamiento y carga cognitiva
• 6. El código no hablará por ti, las personas sí
• 7. El mejor código es esa línea que nunca escribiste
• 8. Cuando la escala es grande, incluso tus bugs tienen usuarios
• 9. La mayoría de los equipos «lentos» en realidad están «desenfocados»
• 10. Concéntrate en lo que puedes controlar, ignora lo que no puedes
• 11. La abstracción no elimina la complejidad, solo la traslada
• 12. Escribir obliga a la claridad, enseñar es la forma más rápida de aprender
• 13. Hacer posible otros trabajos es invaluable, pero invisible
• 14. Si ganas cada discusión, quizás estás acumulando resistencia silenciosa
• 15. Cuando un indicador se convierte en objetivo, deja de ser un buen indicador
• 16. Reconocer «no sé» genera más seguridad que aparentar saber
• 17. Tu contexto es más duradero que cualquier trabajo que hayas hecho
• 18. La mayoría de las mejoras de rendimiento provienen de «eliminar trabajo», no de «algoritmos inteligentes»
• 19. Los procesos existen para reducir la incertidumbre, no para crear documentación
• 20. Al final, el tiempo vale más que el dinero, actúa en consecuencia
• 21. No hay atajos, pero sí efecto compuesto

• Último pensamiento

Addy Osmani, director de IA en Google Cloud, es un ingeniero de software experimentado y pensador, quien fue responsable de la experiencia del desarrollador en Chrome durante casi 14 años, participando en proyectos como DevTools, Lighthouse y Core Web Vitals. Actualmente, coordina el trabajo entre Google DeepMind, ingeniería, producto y relaciones con desarrolladores.

El 3 de día, publicó en su blog personal una profunda reflexión sobre el trabajo. Combinando su experiencia en Google y su profesionalismo, resumió 21 valiosos consejos sobre comunicación, elección tecnológica y planificación de carrera, que a continuación compartimos traducidos y organizados por Zhuangyu:

Cuando me uní a Google hace unos 14 años, pensaba que este trabajo era simplemente escribir código perfecto. Solo acerté en parte. Cuanto más tiempo pasé allí, más me di cuenta de que los ingenieros destacados no necesariamente escriben el mejor código, sino aquellos que aprenden a dominar todo lo que está fuera del código: incluyendo relaciones humanas, política en el trabajo, alineación de consensos y manejo de la incertidumbre.

Estas experiencias me hubiera gustado entenderlas antes. Algunas me ahorraron meses de frustración, otras me tomaron años comprenderlas realmente. Nada tienen que ver con tecnologías específicas: la rápida evolución tecnológica no importa. Se trata de patrones recurrentes en diferentes proyectos y equipos.

Comparto esto porque he aprendido mucho de ingenieros que están dispuestos a apoyar a los que vienen detrás. Es mi forma de devolver un poco.

1. Los ingenieros de élite están obsesionados con resolver problemas de los usuarios

Enamorarse de una tecnología y buscar aplicaciones en todas partes es muy tentador. Todos lo hemos hecho. Pero los ingenieros que generan mayor valor son los que hacen «trabajo inverso»: están obsesionados con entender profundamente los problemas de los usuarios y que las soluciones surjan naturalmente de esa comprensión.

Obsesión por el usuario significa dedicar tiempo a revisar tickets de soporte, conversar con usuarios, observar sus dificultades operativas, preguntar «¿por qué?» hasta llegar a la raíz. Los ingenieros que entienden realmente el problema suelen descubrir que las soluciones elegantes son más simples de lo que imaginaban. Los ingenieros que parten de la solución, a menudo añaden complejidad innecesaria para justificar su enfoque.

2. «Probar que uno tiene razón» no tiene valor, lo importante es alcanzar objetivos correctos en conjunto

Puedes ganar cada discusión técnica, pero perder el proyecto completo. He visto ingenieros inteligentes acumular resentimiento silencioso porque siempre quieren ser los más listos en la sala. Ese costo se manifiesta después en «problemas de ejecución misteriosos» o «resistencia inexplicada».

La habilidad no está en ser «correcto», sino en participar en la discusión para alinear los problemas, crear espacio para otros y mantener la duda sobre tus propias certezas. Fuerte convicción, mente abierta — esto no significa que falte fe en ti, sino que en decisiones en incertidumbre, tu autoestima no debe estar en juego.

3. Enfócate en la acción. ¡Lanza! Puedes modificar páginas malas, pero no páginas en blanco

Perseguir la perfección puede paralizarte. He visto ingenieros discutir semanas sobre la arquitectura ideal de algo que nunca construyeron. La perfección rara vez surge solo del pensamiento — surge del choque con la realidad. La IA puede ayudar en muchos aspectos.

Haz primero, haz correcto, y luego mejora. Lanza prototipos feos a los usuarios. Escribe el borrador de un diseño confuso. Publica ese MVP que te incomoda un poco. Lo que aprendes en una semana de feedback real vale más que un mes de debates teóricos. El impulso trae claridad, el análisis paraliza.

4. La experiencia se refleja en la claridad, la inteligencia en la carga

Es casi universal que los ingenieros tengan un instinto para escribir código «inteligente», que parece una prueba de capacidad. Pero el software es una reacción química entre «tiempo» y «otros ingenieros». En ese entorno, la claridad no es un estilo, sino una reducción del riesgo operacional.

Tu código es un recordatorio estratégico para esas personas que quizás arreglarán fallos a las 2 a.m. Mejora su comprensión, no tu elegancia. Los ingenieros senior que admiro siempre optan por usar «inteligente» para lograr «claro».

5. «Novedad» es un préstamo de alto interés a mantenimiento, reclutamiento y carga cognitiva

Piensa en tus decisiones tecnológicas como si fueras una startup con un «token de innovación» limitado. Cada vez que adoptas una tecnología no estándar, gastas uno. No puedes pagar mucho. La clave no es «nunca innovar», sino «innovar solo donde obtienes recompensas únicas».

Todo lo demás debe considerarse «aburrido», porque lo aburrido tiene un modo de fallo conocido. «La herramienta más adecuada para el trabajo» suele ser «la que menos se degrada en múltiples tareas» — administrar un zoológico tecnológico será una carga real.

6. El código no hablará por ti, las personas sí

En los primeros años, pensaba que un buen desempeño hablaría por sí solo. Me equivoqué. El código permanece en el repositorio en silencio. Lo que importa es si tu jefe menciona tu trabajo en reuniones, si colegas te recomiendan para proyectos.

En organizaciones grandes, las decisiones las toman en reuniones no invitadas, por personas que solo tienen cinco minutos y doce prioridades, basándose en resúmenes que tú no escribiste. Si cuando no estás, nadie puede explicar tu impacto, tu influencia es trivial. No se trata solo de autopromoción, sino de hacer que la cadena de valor sea visible para todos (incluyéndote a ti mismo).

7. El mejor código es esa línea que nunca escribiste

La cultura de ingeniería celebra la creación. Nadie será promovido por eliminar código, aunque eliminar suele optimizar más que añadir. Cada línea de código que no escribiste, es una que nunca tendrás que depurar, mantener o explicar.

Antes de construir, pregúntate: «¿Qué pasa si simplemente no hacemos esto?» A veces la respuesta es «nada malo», y esa es tu solución. La cuestión no es que los ingenieros no sepan escribir código o usar IA para ello, sino que somos tan buenos en escribir que olvidamos preguntar «¿debería hacerse?».

8. Cuando la escala es grande, incluso tus bugs tienen usuarios

Cuando tienes suficientes usuarios, cualquier comportamiento observable se vuelve una dependencia — sin importar lo que prometiste (Ley de Heller). Alguien está llamando a tu API, automatizando tus funciones peculiares, almacenando en caché tus bugs.

Esto genera una visión profesional: no puedes tratar la compatibilidad como «mantenimiento», ni las nuevas funciones como «trabajo real». La compatibilidad es el producto mismo. Cuando diseñas una depreciación, debes verla como una migración con tiempo, herramientas y empatía. La mayoría de las «diseños de API» en realidad son «retiros de API».

9. La mayoría de los equipos «lentos» en realidad están «desenfocados»

Cuando un proyecto se estanca, la reacción instintiva es culpar a la ejecución: falta de personal, mala elección tecnológica. Pero muchas veces no es eso. En grandes empresas, los equipos son unidades de concurrencia, pero el costo de coordinación crece geométricamente con el tamaño. La lentitud suele ser falta de alineación — construyen cosas equivocadas o en formas incompatibles. Los ingenieros senior dedican más tiempo a clarificar dirección, interfaces y prioridades, que a «escribir código más rápido», porque esa es la verdadera restricción.

10. Concéntrate en lo que puedes controlar, ignora lo que no

En grandes empresas, muchas variables están fuera de tu control: reestructuraciones, decisiones de gestión, cambios de mercado, cambios en el producto. Enfocarte en eso solo genera ansiedad y no ayuda. Los ingenieros eficientes se concentran en su círculo de influencia.

No puedes controlar reestructuraciones, pero sí la calidad del trabajo, tu reacción y lo que aprendes. Cuando hay incertidumbre, divide el problema y busca acciones concretas que puedas tomar. No es resignarse, sino estrategia. El tiempo que gastas en lo que no puedes cambiar, es tiempo robado a lo que sí puedes.

11. La abstracción no elimina la complejidad, solo la traslada

Cada abstracción es una apuesta: que no necesitas entender los detalles. A veces ganas, pero las abstracciones siempre tienen fugas. Cuando fallan, necesitas entender qué pasa en el fondo. Los ingenieros senior siguen aprendiendo «bajo el capó» incluso en pilas cada vez más altas. No por nostalgia, sino por respeto a los momentos en que la abstracción falla. Usa tus herramientas, pero comprende sus fallas en el nivel más profundo.

12. Escribir obliga a la claridad, enseñar es la forma más rápida de aprender

Escribir te hace pensar. Cuando explico un concepto a otros — en documentación, presentaciones, revisiones de código, o incluso hablando con IA — descubro mis propias lagunas.

Hacer que el contenido sea claro para otros también lo hace más claro para mí. No solo es compartir conocimiento, sino un autoaprendizaje. Si crees que entiendes algo, intenta explicarlo en pocas palabras. Donde te atasca, es donde tu comprensión es superficial. Enseñar es depurar tu modelo mental.

13. Hacer posible otros trabajos es invaluable, pero invisible

El «trabajo de pegamento» — documentación, onboarding, coordinación entre equipos, mejora de procesos — es crucial. Pero si lo haces sin conciencia, puede obstaculizar tu crecimiento técnico y agotarte. La trampa está en verlo como «ayudar a otros», en lugar de considerarlo una contribución consciente, con límites y visible. Limita el tiempo, alterna tareas, conviértelo en output (documentos, plantillas, automatizaciones).

Debe verse como influencia, no como rasgo de personalidad.

14. Si ganas cada discusión, quizás estás acumulando resistencia silenciosa

He aprendido a cuestionar mi certeza. Cuando gano demasiado fácil, algo anda mal. La gente deja de discutir no porque te convenza, sino porque se rinden — expresan su desacuerdo en la ejecución, no en la reunión. La verdadera alineación requiere más tiempo.

Debes entender realmente el punto de vista del otro, incorporar su feedback, y a veces cambiar de opinión públicamente. La satisfacción de ganar una discusión a corto plazo no se compara con el valor de trabajar con socios que comparten tu visión a largo plazo.

15. Cuando un indicador se vuelve objetivo, deja de ser un buen indicador

Cada métrica que muestras a la gerencia será «manipulada». No por malicia, sino porque las personas optimizan lo que se mide (Ley de Goodhart). Si mides líneas de código, obtendrás más líneas. Si mides velocidad, obtendrás estimaciones infladas.

La práctica avanzada es solicitar un par de métricas por cada indicador: uno para velocidad, otro para calidad o riesgo. Insiste en interpretar tendencias, no en adorar umbrales. El objetivo es insight, no vigilancia.

16. Reconocer «no sé» genera más seguridad que aparentar saber

Un ingeniero senior que dice «no sé» no muestra debilidad, sino que crea «permiso». Cuando los líderes admiten incertidumbre, envían una señal: este espacio es seguro para otros. He visto equipos donde los senior nunca admiten confusión, y eso hace mucho daño: nadie pregunta, nadie desafía, los junior se callan pensando que solo ellos no entienden. Demuestra curiosidad, y tendrás un equipo que realmente aprende.

17. Tu contexto es más duradero que cualquier trabajo que hayas hecho

En los primeros años, me enfoqué en el trabajo y descuidé las relaciones. Ahora sé que fue un error. Invertir en relaciones con colegas dentro y fuera de la empresa ha sido invaluable durante décadas. Ellos escuchan las oportunidades primero, construyen puentes más rápido, recomiendan puestos, y fundan startups con confianza. El trabajo no es para siempre, pero las relaciones sí. Construye con curiosidad y generosidad, no con transacciones.

18. La mayoría de las mejoras de rendimiento provienen de «eliminar trabajo», no de «algoritmos inteligentes»

Cuando un sistema se vuelve lento, la reacción instintiva es agregar cachés, paralelizar, usar algoritmos más inteligentes. A veces funciona, pero he visto más mejoras al preguntar: «¿Qué cosas estamos calculando que no necesitamos?» Eliminar trabajo innecesario casi siempre es más efectivo que acelerar lo necesario. El código más rápido es el que nunca se ejecuta.

19. Los procesos existen para reducir la incertidumbre, no para crear documentación

Los mejores procesos facilitan la coordinación y reducen el costo de fallar. Los peores son «burocracia dramática» — existen para culpar cuando algo sale mal, no para ayudar. Si no puedes explicar cómo un proceso reduce riesgos o aumenta claridad, probablemente solo sea una carga. Si la gente dedica más tiempo a documentar que a hacer, hay un problema grave.

20. Al final, el tiempo vale más que el dinero, actúa en consecuencia

En los primeros años, intercambiaba tiempo por dinero sin problema. Pero en algún momento, esa lógica se invierte. El tiempo es un recurso no renovable. He visto ingenieros agotados persiguiendo un nivel salarial o unos pocos puntos porcentuales en su salario, y muchos se arrepienten después, preguntándose si valió la pena. La respuesta no es «no trabajes duro», sino saber qué estás negociando y hacerlo conscientemente.

21. No hay atajos, pero sí efecto compuesto

El conocimiento profesional viene de practicar deliberadamente — ir un poco más allá de tus habilidades actuales, reflexionar, repetir, y hacerlo durante años. No hay versión reducida. Pero la clave está en que cuando el aprendizaje crea nuevas opciones en lugar de solo acumular conocimientos dispersos, genera interés compuesto. Escribir (para claridad), construir componentes reutilizables, recopilar lecciones en manuales. Los ingenieros que ven su carrera como «interés compuesto» en lugar de «lotería» suelen llegar mucho más lejos.

Último pensamiento

Estas 21 reglas parecen muchas, pero en realidad solo hay unos pocos conceptos clave: mantén la curiosidad, sé humilde y recuerda que el trabajo siempre trata de personas — incluyendo a los usuarios para quienes construyes productos y a los compañeros con quienes colaboras.

La carrera de un ingeniero es larga, lo suficiente para cometer muchos errores y aún así tener éxito. Los ingenieros que más admiro no son los que nunca fallan, sino los que aprenden de sus errores, comparten sus descubrimientos y persisten.

Si estás empezando, sabe que con el tiempo se vuelve aún más interesante. Si ya llevas años, espero que algunas de estas reglas te resuenen.