Mis principios maestros tras 20 años de programación

Esta es una traducción al español de un artículo que me pareció muy interesante, dada su naturaleza, la experiencia de Alex y lo de acuerdo que estoy en, prácticamente, todos los puntos que cita.

He estado programando desde 1999 y este año he programado, oficialmente, durante más de 20 años. Empecé con Basic pero pronto pasé a Pascal y C y luego aprendí programación orientada a objetos (POO) con Delphi y C++. En 2006 comencé con Java y en 2011 comencé con JavaScript. He trabajado con una amplia gama de empresas, desde robótica, tecnología financiera, tecnología médica hasta medios y telecomunicaciones. A veces tenía un papel diferente como investigador, CTO, TPM (director técnico de productos), profesor, arquitecto de sistemas o TL (líder técnico), pero siempre he estado programando. He trabajado en algunos productos que sirvieron a millones de personas y en algunos que fallaron antes de ser lanzados. Trabajé como consultor e incluso tuve mi propia startup. He dedicado mucho tiempo a proyectos de código abierto, proyectos de código cerrado y proyectos internos de código abierto (código propietario desarrollado por una comunidad dentro de la empresa). He trabajado con pequeños microcontroladores hasta aplicaciones móviles y de escritorio, servidores en la nube y, últimamente, serverless.

Para mi 20 aniversario de programación, intenté enumerar los principios fundamentales que se han acumulado a lo largo de los años como mis principios maestros a lo largo de mi carrera:

1. No pelees con las herramientas: bibliotecas, lenguaje, plataforma, etc. Usa tantas construcciones nativas como sea posible. No doblegues la tecnología, pero tampoco doblegues el problema. Elije la herramienta adecuada para el trabajo o tendrás que encontrar el trabajo adecuado para la herramienta que elegiste.
2. No escribes el código para las máquinas, lo escribes para tus compañeros y para ti mismo en el futuro (a menos que sea un proyecto descartable o estés escribiendo ensamblador). Escríbelo para los más inexpertos como referencia.
3. Cualquier pieza de software significativa y gratificante es el resultado de la colaboración. Comunícate de manera efectiva y colabora abiertamente. Confía en los demás y gánate su confianza. Respeta a las personas más que al código. Predica con el ejemplo. Convierte a tus seguidores en líderes.
4. Divide y vencerás. Escribe módulos aislados con responsabilidades separadas que estén débilmente acoplados. Prueba cada parte por separado y en conjunto. Mantén los test cercanos a la realidad, pero testea también los casos extremos.
5. Recházate a ti mismo. No seas la persona a la que acudir para obtener el código. Optimízalo para que las personas encuentren su camino corrigiendo errores y agregando funciones al código. Libérate para pasar al siguiente proyecto/empresa. No poseas el código o nunca crecerás más allá de eso.
6. La seguridad viene en capas: cada capa debe evaluarse individualmente pero también en relación con el todo. El riesgo es una decisión empresarial y tiene relación directa con la vulnerabilidad y la probabilidad. Cada producto/organización tiene un nivel de riesgo diferente (el riesgo que están dispuestos a asumir para obtener una ganancia mayor). A menudo, estas 3 preocupaciones luchan entre sí: UX, Seguridad, Rendimiento.
7. Date cuenta de que cada código tiene un ciclo de vida, y que morirá. A veces muere en su infancia antes de ver la luz de la producción. Siéntete en paz con dejarlo ir. Conoce la diferencia entre 4 categorías de características y dónde poner tu tiempo y energía:
   Núcleo: como el motor en un automóvil. El producto no tiene sentido sin él.
   Necesario: como la rueda de repuesto de un coche. Rara vez se usa, pero cuando es necesario, su función decide el éxito del sistema.
   Valor añadido: como el portavasos de un coche. Es bueno tenerlo, pero el producto es perfectamente utilizable sin él.
   Punto de venta único: la razón principal por la que las personas deberían comprar tu producto en lugar del de tus rivales. Por ejemplo, tu automóvil es el mejor vehículo todoterreno.
8. No asocies tu identidad a tu código. No asocies la identidad de nadie a su código. Date cuenta de que las personas están separadas de su creaciones. No tomes las críticas al código como algo personal, pero ten mucho cuidado al criticar el código de otros.
9. La deuda tecnológica es como la comida rápida. De vez en cuando es aceptable, pero si te acostumbras, matará al producto más rápido de lo que crees (y de forma dolorosa).
10. Al tomar decisiones sobre la solución, en igualdad de condiciones, opta por esta prioridad:
    Seguridad > Confiabilidad > Usabilidad (Accesibilidad y UX) > Mantenibilidad > Simplicidad (Experiencia del desarrollador/DX) > Brevedad (longitud del código) > Finanzas > Rendimiento
    Pero no sigas esto a ciegas porque depende de la naturaleza del producto. Como en cualquier carrera, cuanta más experiencia ganes, más podrás encontrar el equilibrio adecuado para cada situación. Por ejemplo, al diseñar un motor de juegos el rendimiento tiene la máxima prioridad, pero al crear una aplicación bancaria, la seguridad es el factor más importante.
11. La propagación de errores se llama copiar y pegar. Así es como se reproducen. Siempre revisa lo que copias, siempre audita lo que importas. Los bugs se refugian en la complejidad. La “magia” está bien en mis dependencias, pero no en mi código.
12. No solo escribas código para el escenario ideal. Devuelve buenos errores que respondan por qué sucedió, cómo se detectó y qué se puede hacer para resolverlo. Valida todas las entradas del sistema (incluidas las entradas del usuario): falla pronto pero recupérate de los errores siempre que sea posible. Supón que el usuario tiene un arma: ¡pon suficiente esfuerzo en tus errores para convencerlo de que dispare a algo que no sea tu cabeza!
13. No uses dependencias a menos que el costo de importar, mantener, lidiar con sus casos extremos/errores y refactorizar cuando no satisfagan las necesidades sea significativamente menor que el código que ya tienes.
14. Mantente alejado del hype-driven development. Pero aprende todo lo que puedas. Siempre ten proyectos mascota.
15. Sal de tu zona de confort. Aprende todos los días. Enseña lo que aprendes. Si eres el maestro, no estás aprendiendo. Exponte a otros lenguajes, tecnologías, cultura y mantén la curiosidad.
16. Un buen código no necesita documentación, pero un gran código está bien documentado para que cualquier persona que no haya sido parte del proceso de evolución, prueba y error y los requisitos que llevaron al estado actual, pueda ser productivo con él. Una característica no documentada es una característica que no existe. Una característica inexistente no debería tener código.
17. Evita la sobreescritura, la herencia y la inteligencia implícita tanto como sea posible. Escribe funciones puras. Son más fáciles de probar y razonar. Cualquier función que no sea pura debería ser una clase. Cualquier construcción de código que tenga una función diferente, debe tener un nombre diferente.
18. Nunca comiences a codificar (creando una solución) a menos que comprendas completamente el problema. Es muy normal pasar más tiempo escuchando y leyendo, que escribiendo código. Comprende el dominio antes de comenzar a codificar. Un problema es como un laberinto. Debes pasar, progresivamente, por el ciclo de código-prueba-mejora y explorar el espacio del problema hasta llegar al final.
19. No resuelvas un problema que no existe. No hagas programación especulativa. Solo permite que el código sea extensible si es una suposición validada de que se extenderá. Lo más probable es que, cuando se extienda, la definición del problema sea diferente de cuando escribiste el código. No hagas sobreingeniería: concéntrate en resolver el problema en cuestión y en una solución efectiva, implementada de manera eficiente.
20. El software es más divertido cuando se hace en compañía. Construye una comunidad sostenible. Escucha. Inspira. Aprende. Comparte.

No pretendo ser una autoridad en el desarrollo de software. Esto es solo la sabiduría que obtuve en el camino. Estoy seguro de que esta lista será más madura después de otros 20 años.

P.d.- Esta es una traducción al español de un artículo que me pareció muy interesante, dada su naturaleza, la experiencia de Alex y lo de acuerdo que estoy en, prácticamente, todos los puntos que cita.

Hasta ahí llega el artículo original. Desde mi otros más de 20 años de programación, me gustaría añadir un simple principio que me ha ayudado todo este tiempo, mucho más que cualquier otro: KISS (Keep It Simple, Stupid).