Importante, Lea esto primero

Estás a punto de leer una entrada de blog con un montón de consejos. Aprender de los que nos precedieron es fundamental para el éxito, pero a menudo olvidamos una advertencia importante. Casi todos los consejos son contextuales, sin embargo, rara vez se ofrecen con algún contexto.

“¡Sólo necesitas cobrar más!” dice la empresa que ha estado en el negocio durante 20 años y pasó años cobrando “demasiado poco” para ganar clientes y tener éxito.

“¡Necesitas construir todo como microservicios!” dice la empresa que construyó un monolito rápido, ganó miles de clientes, y luego giró a los microservicios a medida que comenzó a encontrarse con problemas de escalamiento.

Sin entender el contexto, el consejo no tiene sentido, o peor aún, es dañino. Si esas personas hubieran seguido sus propios consejos desde el principio, ellos mismos probablemente habrían sufrido por ello. Es difícil escapar de esta trampa. Podemos ser la culminación de nuestras experiencias, pero las vemos a través de la lente del presente.

Un articulo original de Simplethread.

Así que para darles un poco de contexto de dónde viene mi consejo, pasé la primera mitad de mi carrera como ingeniero de software trabajando para varias pequeñas empresas y startups, luego me dediqué a la consultoría y trabajé en un número de negocios realmente grande. Luego empecé “Simple Thread” y pasamos de un equipo de 2 a un equipo de 25. Hace 10 años trabajábamos principalmente con pequeñas/medianas empresas, y ahora trabajamos con una mezcla de grandes y pequeñas empresas.

Mi consejo es de alguien que…

1. casi siempre ha estado en equipos pequeños donde hay que hacer mucho con muy poco.
2. valora software funcionando sobre herramientas específicas.
3. está iniciando nuevos proyectos todo el tiempo, pero también tiene que mantener una cantidad de sistemas.
4. valora la productividad del ingeniero sobre la mayoría de otras consideraciones

Mis experiencias en los últimos 20 años han dado forma a cómo veo el software, y me han llevado a algunas creencias que he tratado de reducir a una lista manejable que espero que encuentre valiosa.

En la lista

1. Todavía no sé mucho

"¿Cómo puedes no saber lo que es BGP?" “¿Nunca has oído hablar de Rust?” La mayoría de nosotros hemos escuchado este tipo de declaraciones, probablemente demasiado a menudo. La razón por la que a muchos de nosotros nos gusta el software es porque somos aprendices de por vida, y en el software no importa en qué dirección mires, hay amplias perspectivas de conocimiento que van en todas direcciones y se expanden cada día. Esto significa que puedes pasar décadas en tu carrera, y todavía tener una enorme brecha de conocimiento en comparación con alguien que también ha pasado décadas en un papel aparentemente similar. Cuanto antes te des cuenta de esto, antes podrás empezar a deshacerte de tu síndrome del impostor y a deleitarte aprendiendo y enseñando a otros.

2. La parte más difícil del software es construir lo correcto

Sé que esto es un cliché a esta altura, pero la razón por la que la mayoría de los ingenieros de software no lo creen es porque piensan que devalúa su trabajo. Personalmente creo que es una tontería. En cambio, pone de relieve la complejidad e irracionalidad de los entornos en los que tenemos que trabajar, lo que agrava nuestros desafíos. Puedes diseñar la cosa técnicamente más impresionante del mundo, y luego no tener a nadie que quiera usarla. Sucede todo el tiempo. El diseño de software es principalmente una actividad de escucha, y a menudo tenemos que ser parte ingeniero de software, parte psíquico y parte antropólogo. Invertir en este proceso de diseño, ya sea a través de miembros dedicados del equipo de UX o simplemente educándote, producirá enormes dividendos. Porque ¿cómo se calcula realmente el costo de desarrollar el software equivocado? Equivale a mucho más que el tiempo de ingeniería perdido.

3. Los mejores ingenieros de software piensan como diseñadores.

Los grandes ingenieros de software piensan profundamente en la experiencia del usuario de su código. Puede que no lo piensen en esos términos, pero sea una API externa, una API programática, una interfaz de usuario, de protocolo o cualquier otra interfaz; los grandes ingenieros consideran quién la usará, por qué se usará, cómo se usará y qué es importante para esos usuarios. Mantener las necesidades del usuario en mente es realmente el corazón de una buena experiencia del usuario.

4. El mejor código es el que no existe, o código que no tiene que mantenerse.

Todo lo que puedo decir es “los programadores van a programar.” Le preguntas a alguien en cualquier profesión cómo resolver un problema, y va a hacerlo desde un área en la que es bueno. Es sólo la naturaleza humana. La mayoría de los ingenieros de software siempre va a resolverlo escribiendo código, especialmente cuando una solución no técnica no es obvia. Lo mismo ocurre con el código que no tienes que mantener. Los equipos de ingeniería son aptos para querer reinventar la rueda, cuando ya existen muchas ruedas. Este es un acto de equilibrio, hay un montón de razones para crecer por ti mismo, pero ten cuidado con el síndrome tóxico “No inventado aquí”.

5. El software es un medio para un fin

El trabajo principal de cualquier ingeniero de software es entregar valor. Muy pocos desarrolladores de software entienden esto, menos aún lo internalizan. Verdaderamente internalizar esto conduce a una manera diferente de resolver problemas, y una manera diferente de ver sus herramientas. Si realmente crees que el software está subordinado al resultado, estarás listo para encontrar realmente “la herramienta adecuada para el trabajo” que podría no ser software en absoluto.

6. A veces tienes que dejar de afilar la sierra, y simplemente empezar a cortar porquerías.

Algunas personas tienden a meterse en problemas y empezar a escribir código. Otras personas tienden a querer investigar e investigar y quedan atrapadas en la parálisis del análisis. En esos casos, fijate un plazo y comienza a explorar soluciones. Aprenderás más rápidamente a medida que comiences a resolver el problema, lo que te llevará a iterar en una mejor solución.

7. Si no tienes una buena comprensión del universo de lo que es posible, no puedes diseñar un buen sistema.

Esto es algo con lo que lucho mucho mientras mis responsabilidades me llevan más y más lejos del día a día de la ingeniería de software. Mantenerse al día con el ecosistema de desarrolladores es una gran cantidad de trabajo, pero es fundamental para entender lo que es posible. Si no entiendes lo que es posible y lo que está disponible en un ecosistema dado, entonces encontrarás que es imposible diseñar una solución razonable para todos los problemas excepto los más simples. Para resumir, ten cuidado con las personas que diseñan sistemas y no han escrito ningún código en mucho tiempo.

8. Todo sistema al final apesta, supéralo.

Bjarne Stroustrup tiene una cita que dice: “Sólo hay dos tipos de lenguajes: aquellos de los que la gente se queja y aquellos que nadie utiliza”. Esto también se puede extender a los grandes sistemas. No hay arquitectura “correcta”, nunca pagarás toda tu deuda técnica, nunca diseñarás la interfaz perfecta, tus pruebas siempre serán demasiado lentas. Esto no es una excusa para nunca mejorar las cosas, sino una manera de darte perspectiva. Preocúpate menos por la elegancia y la perfección; en cambio, esfuérzate por la mejora continua y crea un sistema habitable en el que tu equipo disfrute trabajando y que ofrezca un valor sostenible.

9. Nadie pregunta “por qué” lo suficiente.

Aprovecha cualquier oportunidad para cuestionar supuestos y enfoques que son “la forma en que siempre se han hecho las cosas”. ¿Tienes un nuevo miembro del equipo a bordo? Presta atención a dónde se confunden y qué preguntas hacen. ¿Tienes una nueva solicitud de características que no tiene sentido? Asegúrate de entender el objetivo y lo que está impulsando el deseo de esta funcionalidad. Si no consigues una respuesta clara, sigue preguntando por qué hasta que entiendas.

10. Deberíamos estar mucho más centrados en evitar los programadores 0.1x que en encontrar programadores 10x.

El programador 10x es un mito tonto. La idea de que alguien puede producir en 1 día lo que otro programador competente, trabajador, igualmente experimentado puede producir en 2 semanas es tonta. He visto programadores que escriben 10x la cantidad de código, y luego tienes que arreglarlo 10x la cantidad de veces. La única manera en que alguien puede ser un programador 10x es si los comparas con 0.1x programadores. Alguien que pierde el tiempo, no pide feedback, no prueba su código, no considera casos extremos, etc… Deberíamos estar mucho más interesados en mantener a los programadores 0.1x fuera de nuestros equipos que en encontrar al mítico programador 10x.

11. Una de las mayores diferencias entre un ingeniero senior y un ingeniero junior es que tienen opiniones formadas sobre cómo deberían ser las cosas.

Nada me preocupa más que un ingeniero senior que no tiene ninguna opinión de sus herramientas o de cómo acercarse a la construcción de software. Prefiero que alguien me dé opiniones con las que disiento intensamente a que no tengan ninguna opinión. Si estás usando tus herramientas, y no las amas ni las odias de muchas maneras, necesitas experimentar más. Es necesario explorar otros idiomas, bibliotecas y paradigmas. Hay pocas maneras de nivelar tus habilidades más rápido que buscando activamente cómo otros realizan tareas con diferentes herramientas y técnicas que tú.

12. La gente realmente no quiere innovación.

La gente habla mucho de innovación, pero lo que normalmente busca son ganancias con bajo costo y novedades. Si realmente innovas, y cambias la forma en que la gente tiene que hacer las cosas, espera en su mayoría retroalimentación negativa. Si crees en lo que estás haciendo, y sabes que realmente mejorará las cosas, entonces prepárate para una larga batalla.

13. Tus datos son la parte más importante de tu sistema.

He visto muchos sistemas donde la esperanza era el principal mecanismo de integridad de datos. En sistemas como esos, cualquier cosa que sucede fuera del camino dorado crea datos parciales o sucios. Tratar con estos datos en el futuro puede convertirse en una pesadilla. Sólo recuerda: tus datos vivirán probablemente mucho más que tu “base de código”. Gasta energía manteniéndola ordenada y limpia, valdrá la pena a largo plazo.

14. Busca tiburones tecnológicos.

Las tecnologías antiguas que permanecen son tiburones, no dinosaurios. Resuelven tan bien los problemas que han sobrevivido a los rápidos cambios que ocurren constantemente en el mundo de la tecnología. No apuestes contra estas tecnologías, y reemplázalas sólo si tienes una muy buena razón. Estas herramientas no serán llamativas, y no serán emocionantes, pero harán el trabajo sin tener que perder el sueño.

15. No confundas humildad con ignorancia

Hay muchos ingenieros de software que no expresan opiniones a menos que se les pregunte. Nunca asumas que sólo porque alguien no está lanzando sus opiniones a la cara no tiene nada que añadir. A veces las personas más ruidosas son las que menos queremos escuchar. Habla con las personas que te rodean, busca sus comentarios y consejos. Te alegrarás de haberlo hecho.

16. Los ingenieros de software deben escribir regularmente.

Los ingenieros de software deben escribir regularmente blogs, diarios, documentación y en general hacer cualquier cosa que les requiera mantener afiladas sus habilidades de comunicación por escrito. Escribir te ayuda a pensar en tus problemas y te ayuda a comunicarlos más eficazmente a tu equipo y tu yo futuro. Una buena comunicación escrita es una de las habilidades más importantes a dominar para cualquier ingeniero de software.

17. Manten tus procesos lo más pequeños posible.

Todo el mundo quiere ser ágil en estos días, pero ser “ágil” se trata de construir cosas en trozos pequeños, aprender y luego iterar. Si alguien está tratando de calzar mucho más que eso, entonces probablemente está vendiendo algo. No es para decir que la gente no necesita responsabilidad o ayuda para trabajar de esta manera, pero ¿cuántas veces has escuchado a alguien de tu empresa de tecnología favorita o gran proyecto de código abierto alardear de lo grande que es su proceso Scrum? Mantente apoyado en el proceso hasta que sepas que necesitas más. Confía en tu equipo y responderá.

18. Los ingenieros de software, como todos los humanos, necesitan sentirse propietarios.

Si se divorcia a alguien del resultado de su trabajo, le importará menos su trabajo. Veo esto casi como una tautología. Esta es la razón principal por la que los equipos multifuncionales funcionan tan bien, y por la que DevOps se ha vuelto tan popular. No se trata de concesiones e ineficiencias, se trata de ser dueño de todo el proceso de principio a fin, y ser directamente responsable de entregar valor. Dale a un grupo de personas apasionadas completa propiedad sobre el diseño, la construcción y la entrega de una pieza de software (o cualquier cosa realmente) y sucederán cosas increíbles.

19. Las entrevistas son casi inútiles para decir qué tan buen miembro del equipo será alguien.

Las entrevistas se aprovechan mucho mejor tratando de entender quién es alguien, y lo interesado que está en un determinado campo de experiencia. Tratar de descubrir lo bueno que será como miembro del equipo es un esfuerzo infructuoso. Y créanme, lo inteligente o conocedor que es alguien tampoco es un buen indicador de que será un gran miembro del equipo. Nadie te va a decir en una entrevista que va a ser poco fiable, abusivo, pretencioso, o que nunca aparecerá a las reuniones a tiempo. La gente podría decir que tiene “señales” para estas cosas… “si preguntan sobre el tiempo libre en la primera entrevista, entonces nunca van a estar allí!” Pero todo esto es mentira. Si estás usando señales como estas, solo estás adivinando y rechazando buenos candidatos.

20. Esfuérzate siempre por construir un sistema más pequeño.

Hay muchas fuerzas que te empujarán a construir un sistema más grande por adelantado. La asignación presupuestaria, la incapacidad de decidir qué características deben cortarse, el deseo de entregar la “mejor versión” de un sistema. Todas estas cosas nos empujan con mucha fuerza a construir en exceso. Debes luchar contra esto. Aprendes tanto construyendo un sistema que terminarás iterando hacia un sistema mucho mejor que el que podrías haber diseñado de entrada. Esto es sorprendentemente difícil de vender a la mayoría de la gente.

¿Cuál es tu historia?

Así que ahí lo tienen, 20 años de software destilado en 20 piezas concisas de sabiduría. Me encantaría escucharlo si algo resonó con ustedes. También me encantaría saber si tienes un poco de sabiduría que has aprendido durante tu carrera que te gustaría compartir. Siéntase libre de dejarlo en los comentarios. NdE: Link al articulo original para dejar comentarios.

Traducción por anaquinpm, revisó @jedux y cronspace