Software engineering rules
En este post dejo de manifiesto reglas, leyes y normas que sigo dia a dia y fui aprendiendo durantes estos años en la industria. Intentaré respaldarlas con ejemplos concretos para darles un marco conceptual y puedas entender el motivo de cada una.
Muchas reglas seguramente no sean objetivamente correctas, muchas serán polémicas y te harán ruido, incluso muy posiblemente deje de respaldar algunas en algún momento y puede que cambie de opinión en ciertas cosas, de cualquier modo, todas estarán basadas en mi experiencia personal y laboral.
Antes de cada bloque de texto habrá una fecha que indicará en qué momento fue escrito dicho bloque. Por si más adelante hay actualizaciones.
#1 - Nuestra labor es solucionar problemas.
Fecha: Jul 25, 2024
Nuestro trabajo es solucionar problemas, no programar. La programación como actividad es solo un medio y no un fin en sí. No vale la típica de “Java no me gusta”, “Solo programo en Javascript”, “Soy frontend, no me gusta el back”, “No necesito aprender back, si yo hago front, para qué quiero eso”. Tu trabajo como developer o ingeniero (el título que más te guste) no se mide por qué herramientas usas, sino por lo que sabes y sabes hacer.
Muchas veces le damos demasiada importancia a lenguajes, frameworks o librerias, pero todo eso al final de cuentas son herramientas que depende de vos hacerlas rendir o no.
Alguna vez viste a un carpintero usar solo un serrucho para trabajar y decir “Yo uso serrucho nada más, no me gusta usar el martillo”. Esto es completamente trasladable a nuestro rubro.
#2 - Primero los fundamentos, luego las abstracciones
Fecha: Jul 25, 2024
Un error que cometo frecuentemente e intento evitar es el de abstraerme de todos los fundamentos. Hoy en dia no es fácil frenar ciertos niveles de abstracción. ¿Por qué aprendemos a usar React sin tener conocimientos avanzados en Javascript? ¿Por qué necesitamos librerías para absolutamente todo?
No estoy, bajo ningún concepto, en contra de las librerías (en la siguiente regla hago el descargo). Suelo emplear miles todos los días. Pero cada vez más las librerías nos alejan de las dificultades al punto de no tener ni las más remota idea de qué está ocurriendo detrás de escena, dejándonos con la única tarea de ‘armar un lego’ y esperar que todo funcione correctamente.
#3 - Teoría 🤝 práctica
Fecha: Jul 25, 2024
No puede existir una sin la otra. Sin embargo suelo darle más ponderación a la práctica.
La teoría es conocimiento y utilidades que el autor te ofrece, pero nunca vas a terminar de asimilar lo aprendido si no lo empleas en algún momento.
Jamás, nunca, nadie, aprendió a programar leyendo libros, viendo videos o articulos en Dev.to (seguime si estás leyendo esto 😅). Tampoco nadie aprendió a programar sin estudiar previamente.
#4 - No discutir subjetividades
Fecha: Jul 25, 2024
Esta ciencia tiene cierto agregado subjetivo en muchos temas. A medida que el software fue ocupando más espacio y cubriendo más necesidades con el avance del tiempo, se fue humanizando cada vez más, al punto de que en ciertas ocasiones las discusiones estén totalmente sesgadas por nuestras opiniones.
La eterna pelea de: “Java es mejor”, “Javascript es un lenguaje de juguete” son los ejemplos más claros. Sabemos que ninguna opción es la correcta, y todos tienen sus pros y contras pero aún así nos gusta discutir estas cosas. BTW java te odio.
#5 - Priorizar el factor humano
Fecha: Jul 25, 2024
Somos los humanos los que movemos la industria (por ahora), creamos y leemos código todo el tiempo, creamos y directa o indirectamente consumimos productos digitales todo el tiempo. Por eso:
- Cuando estoy creando un producto debo hacerlo pensando en la experiencia del usuario final.
- Cuando creo una librería debo hacerla priorizando la experiencia de desarrollo.
- Cuando escribo código debo ser empático y ponerme en los pies del compañero para que, sin tener mucha información previa, pueda entender fácilmente lo que hice en algún momento.
- Si escribo documentación debo ser lo más claro posible, dar ejemplos y no usar una cantidad de vocabulario técnico excesiva, como si le estuviera explicando a mi tía Pepa.