7 hábitos simples del 1% superior de los ingenieros

• "Cómo los codificadores de élite logran rendir por encima de los demás"

Sé un ingeniero, no un coder (Be an engineer, not a coder)

• La ingeniería consiste en resolver problemas
• Los mejores ingenieros piensan en el código como un medio para alcanzar un objetivo
• Es divertido escribir código, pero escribir código sin propósito no tiene sentido. En cambio, el código se usa para diseñar soluciones para los usuarios
• ¡Programar busca la creatividad! La creatividad suele surgir dentro de restricciones. Si agregas la "restricción" de un problema claro por resolver, el ingeniero puede disfrutar de la libertad de explorar y crear soluciones de la manera que considere adecuada
• Los mejores ingenieros están centrados en el producto y, por encima de todo, priorizan resolver problemas para las personas, lo que lleva al siguiente punto

Código para humanos, no para la computadora (Code for the human, not the computer)

"Cualquiera puede escribir código que una computadora entienda. Los grandes programadores escriben código que los humanos pueden entender." - Martin Fowler

• El código no es solo para la computadora, también es para las personas
• El código es para los ingenieros del mismo equipo que lo leen, lo mantienen y construyen sobre él
• El código es para los usuarios: un niño pequeño que usa un teléfono, un desarrollador que llama una API, o incluso tú mismo
• Los mejores ingenieros siempre evaluaban el valor del código para todos los usuarios
• Si no lograba satisfacer aunque fuera a uno de esos clientes, ese código no llegaba a producción

Desapégate del código en sí (Detach from the code itself)

• Un gran ingeniero no se obsesiona con el código en sí
• No temen borrar y empezar de nuevo incluso un código que ya está 90% terminado si el resultado final va a ser mejor en conjunto
• Aceptan activamente el feedback porque el código no es algo personal
• El código no es perfecto. A nadie le importa el código perfecto. Lo que importa es el código que genera cambios
• La mejor forma de enseñarte a no apegarte demasiado al código es "darte cuenta de que, dentro de 20 años, gran parte de tu código probablemente será deuda técnica, dejará de usarse o será reescrito"

Usa estándares consistentes (Use consistent standards)

• Al escribir código, apegarse a estándares consistentes y a un estilo de codificación uniforme
• Mantener la consistencia permite que tu yo del futuro y tu equipo puedan leer y entender el código más fácilmente
• Usar una guía de estilo consistente hace que tanto el equipo como la base de código sean más fáciles de escalar
  • Así es como empresas como Meta o Google despliegan grandes cantidades de código rápidamente sin que, con el tiempo, su base de código se vuelva ilegible o imposible de mantener
• Todas las empresas de alto desempeño han internalizado las guías de estilo, conocen sus beneficios y las siguen tanto como pueden
  • Google ha publicado parte de sus guías de estilo como open source
  • Meta tiene una guía de estilo de C++ en algunos de sus proyectos open source
• Tip: configurar un linter para el formateo de tu equipo definitivamente vale el tiempo invertido

Escribe código simple (Write simple code)

• Todos los ingenieros de élite que conozco tal vez creaban soluciones complejas al inicio, pero al final producían código fácil de leer y entender
• La mejor forma en que lo he descrito es que su código era "estéticamente satisfactorio"
• Su código era limpio, ordenado y lógico (clean, organized, and logical)
• Cada decisión tomada en el código tenía sentido y, cuando no era así, quedaba bien documentada dentro del propio código
• Una buena forma de escribir código limpio es seguir principios como SOLID. Aunque se diseñaron pensando inicialmente en OOP (programación orientada a objetos), pueden extenderse a la programación en general
  • Single Responsibility: una clase debe tener una sola responsabilidad
  • Open-Closed: los objetos de software (clases, módulos, etc.) deben estar abiertos a la extensión, pero cerrados a la modificación, para crear código predecible y mantenible
  • Liskov Substitution: los subtipos deben poder sustituirse por sus tipos base sin afectar la corrección del programa
  • Interface Segregation: el código no debe depender de una interfaz gigante que no usa por completo. En su lugar, debe permitirse que los paquetes contengan e importen interfaces más pequeñas y específicas
  • Dependency Inversion: los módulos de alto nivel no deben depender de módulos de bajo nivel; ambos deben depender de abstracciones para fomentar un diseño de sistemas más flexible y desacoplado
• Un ejemplo de esto es el naming: los buenos nombres no contienen valores mágicos, distinguen con claridad y expresan nombres de funciones descriptivos y variables fáciles de entender

No permitas sorpresas (Don’t allow surprises)

• El código no debe producir resultados inesperados. Esto es posible siguiendo principios de código y escribiendo pruebas adecuadas
• El buen código es predecible
• Las pruebas refuerzan la claridad y la previsibilidad del código, y dan confianza. Con buenas pruebas automatizadas, el equipo puede cambiar código sin preocuparse por romper partes que no ve
• Algunos tipos de pruebas
  • Pruebas unitarias para componentes individuales y funciones aisladas
  • Pruebas de integración para las interacciones entre varios componentes
  • Pruebas end-to-end para evaluar la funcionalidad del sistema completo desde la perspectiva del usuario
• Las pruebas deben ser simples. Al leer una prueba fallida, debería ser fácil identificar qué salió mal
• También es importante saber qué no se debe probar
  • Por ejemplo, si el esfuerzo de una prueba end-to-end es mayor que el beneficio real para el programa, puede sustituirse por documentación cuidadosa, monitoreo y alertas enviadas a las personas adecuadas (por ejemplo, el owner del código)
  • Además, las pruebas no deben validar detalles de implementación dentro del código, como probar selectores CSS específicos en código frontend o usar únicamente data attributes o pruebas de screenshot

Comunícate seguido (Communicate often)

• Los grandes sistemas no se construyen en solitario. Los grandes ingenieros pasaban por revisiones de diseño, pedían feedback y seguían iterando sobre el diseño inicial del código
• Todo el mundo tiene vacíos en su conocimiento que otra persona puede ayudar a llenar. Una nueva perspectiva a menudo puede ayudar a hacer el código más claro o aportar un enfoque nuevo que antes no se había considerado
• Los mejores ingenieros valoran la comunicación y la colaboración, y no temen tomarse el tiempo de trabajar con otros para obtener un mejor resultado final
• Puede ser tan simple como hacerle ping a un compañero para una revisión rápida de un documento o agregar reviewers a un pull request importante

Programa rápido... y lento (Code fast… and slow)

• Los mejores ingenieros que conozco terminan proyectos rápido, pero programan lento
• ¿Suena extraño?
  • Todos los principios y hábitos anteriores agregan más tiempo a la primera etapa de la codificación. Pero, gracias a ellos, el ingeniero puede hacer avanzar el proyecto paso a paso
  • Dedicar tiempo a usar estándares, probar correctamente, aplicar principios y comunicarse con frecuencia puede ahorrar mucho más tiempo a largo plazo
• Lo viví personalmente cuando era intern y junior engineer, y muchos otros ingenieros también: por apresurarte a avanzar 3 pasos, puedes terminar chocando con un obstáculo y retrocediendo 5

No sigas las reglas a ciegas (Don’t follow rules blindly)

• Las "reglas" y los "principios" anteriores son solo lineamientos. No todo encaja perfectamente dentro de una guía
• A veces, el código que estás escribiendo puede ser un cuadrado que no entra en un círculo, y está bien
  • En ese caso, documenta por qué el código fue escrito de cierta manera
  • De lo contrario, alguien como tu yo del futuro puede ver el código después y pensar: "Vaya, qué tonto era entonces. ¿Por qué esto no sigue nuestros estándares?"
  • Y luego pasará 20 horas recodificándolo para ajustarlo al estándar, solo para llegar a la misma conclusión de antes
• La realidad del desarrollo de software es que no todo el código puede ser limpio ni seguir las reglas a la perfección
• Pero sí puede existir código consistente, limpio, fácil de entender, testeable y valioso
• Otros patrones que encontré en los mejores ingenieros
  • Tienen un conocimiento profundo de dominio en al menos un área. Todos los ingenieros que registré se convirtieron en expertos al enfocarse en un área específica, como infraestructura frontend, sistemas distribuidos o UI limpia, y por eso hoy ocupan los primeros puestos en ese campo
  • Saben hacer marketing personal de forma frecuente y adecuada. Estos ingenieros no se escondían en lugares donde nadie los veía. Todas las personas que trabajaban con su equipo conocían su valor y su expertise, y eso fue resultado de un marketing apropiado y de llevar adelante proyectos de alto impacto

[greety]

Obtuve muy buenos insights. Gracias :)

[geekbini]

¡Qué buen texto!

[nina514]

La tecnología también es importante, pero esto realmente me hace pensar una vez más que lo más importante es crear productos que beneficien a las personas!!!

[functor]

¡Gracias por el buen artículo!

[functor]

Ahora que lo veo, se supone que son 7 hábitos, pero en realidad el contenido tiene 9 jajaja

[xguru]

Yo también las conté... ¡creo que la última y la primera son solo el título! jaja

[saalome]

Vaya, es un gran texto con el que casi todo da mucha empatía jaja

[saalome]

De todos los textos de este tipo que he visto hasta ahora, este es contenido de otro nivel.

[rsm0503]

Es un buen texto que, con una pequeña generalización, podría ayudar a cualquiera.

[kuroneko]

Esto ya parece más una traducción que un resumen, pero... muchas gracias por el resumen.
Es un texto que vale la pena releer de vez en cuando.

[piriri11]

La verdad, sí jajaja. Yo también quiero volver a leerlo varias veces.