Forem: Nehuen Covelo

Desarrollar no es solo código

Nehuen Covelo — Wed, 03 Jan 2024 00:40:00 +0000

El pensamiento común que la gente suele tener es que la tarea de un desarrollador es prácticamente solo programar lo que se le pide, y mi idea con esta lectura es un poco mostrar que no se trata solo de escribir código todo el día. Explicar para los que no han desarrollado una solución, o que no tienen tanta experiencia todavía en el rubro, el desafío que significa mejorar en este tipo de trabajo. Muchos han entrado porque se "paga bien", y se han encontrado con picos de frustración y stress que a veces pareciera que no lo valieran. Justamente no es solo escribir código, o como dicen muchos "copiar y pegar código de stack overflow", sino que se debe adquirir la mayor cantidad de conocimiento sobre la solución y los contextos en que se la debe usar. Y casi todos los conocimientos por fuera del aspecto técnico, muchas veces categorizadas a grandes rasgos como "reglas de negocio", son específicos de la empresa y/o rubro para el que trabajemos. De esta forma el trabajo como desarrollador puede ser muy variable, y personas que trabajan con los mismos lenguajes de programación pueden estar aplicándolo para situaciones extremamente diferentes, al punto que no podrán cambiar el código del otro sin tener un tiempo para incorporar y entender todo lo que se construyo antes.

Foto de Oren Yomtov en Unsplash

Antes de empezar a leer: Muchas cosas que escribo pueden deprimir a alguno que esté pensando en dedicarse a esto, pero también tómenlo como mi experiencia en este rubro, siendo una visión totalmente subjetiva. Puede ser que escuchen de otras personas algo totalmente diferente, como que es súper fácil, aprendes a programar y ya esta, no tenés que hacer ninguna otra cosa. No es mi intención destruir sus esperanzas, pero si destruir un poco esa visión simplista de este trabajo, la cual ha frustrado a muchos y ha engendrado monstruos(influencers), que al final no saben desarrollar, pero si vender la realidad ideal de "ser un desarrollador es lo mejor". Entonces, si probaste programar, y te gusta, termina siendo muy satisfactorio trabajar de esto, pero solo si sabes las horas de estudio y práctica que conlleva.

Lo básico para desarrollar

Esta sección es parcialmente omitible, pero no esta de más decirlo. Para desarrollar es necesario conocimiento en uno o más lenguajes de programación, y principalmente saber que no será el único que aprendamos, que será algo seguro que tengamos que aprender cosas específicas para cada entorno que vamos a trabajar. Es un rubro donde no existe un "esto es lo que siempre funciona", y siempre existe una necesidad de innovación. Lo cual significa que para uno progresar en este área es necesario acostumbrarse aprender cosas nuevas, sobre todo a nivel técnico.

Voy a parar a dar un aviso para aquellos que quieran empezar su carrera como desarrolladores, o ya estén haciendo algún curso/capacitación. No existe ningún tipo de capacitación que les certifique que ustedes "saben desarrollar", así como también ningún título universitario en Ingeniería los convierte automáticamente en Senior. Me parece bien, y apoyo, que la gente haga capacitaciones y/o estudie carreras formales, pero sepan que para el área de desarrollo necesitan más que eso. No esperen ser contratados, ni menos aún ser el mejor desarrollador/programador, por tener terminado un curso hecho online. No paren de estudiar y practicar una vez que terminan alguna capacitación, tienen que seguir desarrollando soluciones aunque sean videos tutoriales. Y lo más importante es no "copiar y pegar" lo que hacen los videos, es que realmente intenten entender por qué escriben el código que escriben. Antes de empezar a pensar en trabajar, sepan que no tienen que saltearse la parte de practicar mucho, porque aunque muchas cosas a nivel técnico vayan a aprenderlas con el mismo trabajo, es necesario que tengan una base sólida de conocimientos básicos. No piensen que tener hecho un curso de introducción a la programación va a ser suficiente, porque hacer un for loop no va a servir de mucho si no sabes en qué situación y para que cosa querés aplicarlo.

Como para no terminar este bloque con un sabor amargo, la alta demanda de desarrolladores es real, pero no buscan cualquier tipo de desarrollador, no buscan a uno más del montón que termina una capacitación, justamente hay un alta demanda por contratar desarrolladores competentes, que sobre todo no les dé miedo aprender cosas nuevas.

Lo básico para trabajar

Obviamente hay un checklist casi obligatorio a completar, como: portafolio o repositorio con código de nuestra autoría, tener un perfil en LinkedIn y un CV actualizado. Saber que las primeras entrevistas sean difíciles, y que probablemente no haya siquiera un feedback de las mismas(es lo que suele pasar). Si no tuvieron experiencia laboral todavía, definirse como fullstack puede ser un error muy grande, y lo que los ayude a estar más tiempo sin encontrar trabajo. Lo que yo siempre recomiendo es que se definan en especializarse en Frontend o Backend, porque en la práctica ser fullstack y saber hacer algo realmente requiere de mucha experiencia y conocimientos, entonces ser fullstack y no tener experiencia para muchos significa que no sabes ni de Front ni de Back. Además de que son muy pocas las empresas que emplean fullstack, y que llegado el momento realmente se desempañan como fullstack. Obviamente acá va a entrar un montón de gente diciendo "Ah no, porque la empresa X, Y y Z buscan fullstacks", puede ser, pero no van a contratar fullstacks que no sepan tengan una base mínima de conocimiento en las dos áreas. Y sepan también que las búsquedas laborales suelen ser hechas por gente que no sabe nada de los conocimientos técnicos que realmente se piden, y al llegar a la entrevista lo que quieren es un Fullstack barato, Junior o trainee, pero que tenga un mínimo de conocimiento como si fuese SemiSenior.

De las cosas más fundamentales para empezar un trabajo como desarrollador es mostrarse predispuesto a aprender, y sepan que lo van a necesitar. Sobre todo el primer tiempo no van a hacer código, o si lo hacen será muy poco. Las primeras dos semanas sobre todo, tendrán que empezar a ver los procesos que tenga la empresa, lo que sea referido a la producción de código(tests, PR review, deploy, etc.) y también a los procesos administrativos(solicitar tickets a otros equipos, solicitar vacaciones a RRHH, etc.). Además, y lo más importante, tendrán que hacer la instalación de todo el ambiente y software necesarios para desarrollar, lo cual suele ser un fastidio hasta para los desarrolladores más experimentados. Mientras hagan todo esto, van a tener dudas, no hay forma que no les pase que van a instalar alguna cosa del ambiente local y va a romperse porque van a faltar las variables de entorno(FACT). No tarden en preguntar, apenas tengan alguna duda vayan al grupo general de su equipo de desarrolladores y pongan lo más detallado lo que hicieron y muestren donde es que les dio error, y sobre todo muy importante: Digan(o compartan una screenshot) cuál es el error que les dio. Siempre, ante cualquier error, cuando vayan a solicitar ayuda por favor pongan que error están recibiendo, muchas veces es algo medio tonto y cuando una persona ve lo que estás recibiendo de error puede darte una respuesta mucho más rápida sin tener que esperar. A los desarrolladores no les molesta que les pregunten y pidan ayuda, pero intenten recordar lo que hicieron para solucionar un problema, si es necesario anótenlo en una libreta o algo, porque de esa forma ustedes van a poder ayudar a otro nuevo compañero que llegue al mismo error. Lo que si es molesto, y lo digo por experiencia propia, es que todos los días pregunten justamente por el mismo error, en la misma situación con las mismas condiciones.

¿Los desarrolladores siempre los van a ayudar que fuese posible? Sí. Pero es importante aprender a solucionar algunos problemas, sobre todo a nivel código. Cuando empezamos a ver el código con el que trabajaremos en el día a día probablemente usemos tecnologías y librerías que nunca escuchamos nombrar, y no tenemos ni idea de como funcionan. Es importante que estudiemos un poco esas tecnologías, al menos buscar un videotutorial de para qué sirve, para anticiparnos un poco al momento de cuando tengamos que hacer algo con eso. Si no empiezan a anticipar las tecnologías que necesitan aprender, van a quedar si o si esperando la ayuda de algún otro desarrollador todo el tiempo, el avance para interiorizar esa tecnología va a ser mucho más costosa. El no hacerlo, hará que sean una carga para el equipo. Aunque volviendo al punto anterior, no tengan miedo en pedir ayuda, hay problemas que realmente puede ser algo que no esté funcionando bien, o que esté mal planteado. Solo estén seguros de agotar algunas opciones antes, como por ejemplo hacer una búsqueda en Google con el problema que tenemos.

Lo básico para dejar de ser un básico

Acá ya son avances que tendrán que hacer como desarrolladores, y no necesariamente al principio de su carrera, para entrar en categorías como Semi Senior por ejemplo. Es importante marcar que no existe algo que pueda decir "sos Junior" o "sos Semi Senior" absolutamente, puede que haya grises, que estén en más cerca de uno o más cerca del otro. La diferencia principal está en la capacidad para resolver tareas sin necesidad de ayuda/supervisión directa, y esta característica aplica ampliamente al terreno técnico. Por lo cual es necesario evaluar otras características, sobre todo cuando quieran ser promovidos en la misma empresa que están trabajando. Una muy importante es interiorizar las reglas de negocio, o sea entender los requerimientos generales que tiene el sistema a nivel negocio. A la empresa no le va a servir promocionarte de su lado si después de un tiempo todavía no aprendiste siquiera lo básico de como funciona el producto en el que trabajas, y es necesario todas las veces utilizar un tiempo para explicarte contexto de la tarea. Conocer el producto, y entender la idea del mismo, es muy importante para avanzar y ser más eficiente en tu trabajo. Y por último quiero nombrar una característica muy necesaria en los desarrolladores más avanzados(que no siempre está presente) y que es vital para desarrollo del equipo, ser proactivo y saber como ayudar. Quiero parar a reflexionar en el como ayudar, porque hay una diferencia ínfima, pero muy importante que puede ayudar a que un equipo sea un equipo increíble, o un equipo tóxico. Para lo cual voy a plantear la misma situación, donde otro desarrollador tiene un problema que no puede resolver, y yo sé como podría ser resuelto(sea porque ya tuve el mismo problema, o tengo el conocimiento suficiente para lograr destrabarlo). Yo resuelvo el problema, y al enviarle la solución puedo:

No explicarle por qué hice lo que hice, evitar que me pregunte por qué o como llegue a ese arreglo, enviar la solución sin avisarle, etc.
Darle una breve explicación de lo que pensé, explicarle que era lo que estaba confundido o donde estaba haciendo mal, proponer diferentes soluciones para considerar, etc.

Son dos formas totalmente diferentes de llegar al mismo resultado donde se resuelve el problema, pero que alimenta una cultura buena y cooperativa, o una tóxica y egoísta. Resalto este último punto porque no dejamos de ser personas en lo laboral, y las actitudes que tengamos afectan de una forma u otra al equipo de trabajo.

Como ser un desarrollador completo

En este bloque intentaré apuntar algunas características que yo espero encontrar en lo que sería una persona Senior. Para lo cual es necesario marcar que la diferencia de experiencia y conocimientos entre Senior y SemiSenior, es mucho más grande que la que existe entre Junior y SemiSenior. Y sinceramente, lo que muchas veces se espera de una persona Senior es algo totalmente diferente a alguien considerado SemiSenior, debido a que los conocimientos más profundos y necesarios son a nivel infraestructura, y no tanto del código que pueda producir. O sea, ¿Un Senior no escribe código? Si, también escribe código y se espera en la gran mayoría de los casos que lo haga, y que lo sepa hacer con un nivel también muy bueno. En los casos que no se escriba código estaríamos hablando de un trabajo como Arquitecto de Soluciones, o algo por el estilo.

De un Senior esperamos:

Que tenga un conocimiento amplio de la infraestructura que utiliza para desarrollar sus soluciones, tanto a nivel productivo como del entorno de desarrollo. Que pueda modificar esos entornos de desarrollo, y que en caso de ser necesario adaptarse a una nueva infraestructura.
Que pueda diagramar punta a punta cuáles serán los servicios y/o flujos necesarios para satisfacer una nueva necesidad de negocio, a veces conocido como "System Design"(no confundir con Design System). Y cuando se solicitan modificaciones estructurales de un producto o servicio, por lo menos tener una idea de donde debe llevarse a cabo la modificación.
Saber delegar tareas, porque un Senior en teoría tendría que poder hacer todo, pero física y temporalmente no es tan fácil. Tiene que tener una mínima idea de cuál es la dificultad que conlleva hacer cada tarea, de esa forma será fácil saber que personas podrán ejecutarla según el seniority y experiencia de cada uno.
Entender los límites que existen, a nivel infraestructura, código, tiempo, servicios, etc.
Que sepa transmitir conocimientos, a través de documentación o dando mentoría directa a otros desarrolladores. Lo cual es esencial para el desarrollo del equipo como un todo.
Poder entender la viabilidad técnica para realizar una tarea. Porque no será nunca el fin de solicitudes de misiones imposibles de los stakeholders.
Amplio conocimiento en diferentes patrones, paradigmas y organización de código. Porque una persona con muchos años de experiencia diciendo que Java con POO es lo único que necesitas, es probablemente un tiro en el pie.
Ser una persona(opcional).

¿Por qué cierro la lista de esta forma? Sencillamente porque lo que realmente se suele espera de un Senior es mucho, y sobre todo pensando que hoy en día se espera todo eso de una persona que tenga mínimo 4 años de experiencia laboral, para lo cual puede no ser tiempo suficiente para lograr tener un check en cada una de estas cosas. Esto seria desde mi perspectiva un Senior ideal, para lo cual he tomado de referencia los pocos ejemplos reales con los que he tenido el gusto de trabajar. Así como también tengo un montón de ejemplos negativos de muchos que me costaría siquiera encasillarlos siquiera como SemiSenior. Para lo cual es necesario saber que el seniority de una persona siempre estará dado desde la perspectiva de quien lo analiza, en este caso yo soy más minucioso y exigente en las características que uno debe tener para cierto Seniority. Las empresas en general usan otras cosas, como por ejemplo el tiempo de experiencia laboral, donde hay casos que de empresas que piden que un Junior tenga 2 años de experiencia, u otras que piden un Senior con solo 4 años de experiencia. En mi caso no utilizo mucho como referencia el tiempo laboral(excepto que sea caso muy extremo, no hay forma que alguien sea Senior con solo 2 años de experiencia), porque he visto casos, me atrevo a decir que muchos, donde gente que tiene 10 años o más de experiencia no puede llegar a plantear soluciones simples y básicas. Me refiero a que haber estado 10 años desarrollando landing pages(solo hacer maquetado y alguna que otra llamada a un backend para enviar un formulario), no puede automáticamente convertirte en Senior, o como mucho serás Senior en maquetado de páginas institucionales.

TL;DR:

El trabajo como desarrollador va mucho más allá de saber principios básicos de programación, aunque aprender eso sea un comienzo para esta carrera. Para desarrollarse como profesional en este área exige capacitarse y aprender más que una única tecnología, y para lo cual no existe un curso que los deje listos para trabajar. La alta demanda de desarrolladores es real, pero no significa que contratan a cualquier persona que tenga hecho una simple capacitación, tienen que crear y mantener un portfolio y/o repositorio con varios proyectos que demuestren su conocimiento.
Una vez en su primer trabajo, deberán adoptar ciertas actitudes si es que no las tienen todavía para poder adaptarse mejor al rubro, como solicitar ayuda siempre que no podamos resolver un problema y ser más proactivos al momento de alguien tener inconvenientes. Y entre los diferentes Seniorities(Jr, SSR, SR) se pueden remarcar cuáles son las diferencias esenciales que hay entre ellos. La diferencia de Junior a SemiSenior es más fluida y acotada, pero hay un abismo de conocimientos y características que difieren a un SemiSenior de un Senior.

Sobreingeniería, y el mal de abstraer todo a mi alrededor

Nehuen Covelo — Thu, 19 Oct 2023 17:34:37 +0000

Artículo de la serie ¿Que es escalable?, Y que lo es en el desarrollo frontend?.

Foto de Wil Stewart en Unsplash

En el ambiente de IT, en mi caso en el desarrollo de aplicaciones y sistemas, siempre se intenta abstraer todas las entidades con las que trabajamos. Siendo el objetivo: poder clasificar, englobar y entender los objetos con los que tenemos que lidiar en nuestros proyectos. Se intenta no dejar suelta ninguna variable al azar, desestimando el problema principal, que nuestro sistema es operado por un gran factor de azar, el usuario. Y cuando vamos a nuestro frontend, al usuario no le va a importar si el código que está corriendo por detrás es escalable o no, las tecnologías que se utilizaron, etc.

Se cuestiona así la actividad del poeta. Es como si en lugar de ejercer esta libertad inventiva, la tarea del poeta hubiera sido primordialmente la de construir una unidad engañosa.
- Juan Luis Vermal, sobre la relacion de Poesía y verdad en Nietzche

Vease al desarrollador/ingeniero de software como este poeta, que va a describir su sistema basado en las demandas que tiene. Algunos sistemas serán simples hasta en su definición y no necesitan ningún tipo de complicación. Pero existe el arte de complicar las cosas, creando e imaginando problemas donde todavía no existen. Y en mi camino como desarrollador encontré mucha gente con una gran facilidad para complicar las cosas, en todos los sentidos posibles, habidos y por haber.

Me adjudico aquí la siguiente frase que no estará directamente entendida al contexto que estamos hablando, pero espero que al terminar la lectura se entienda. Luego, dejando esta ruidosa introducción atrás, comenzaremos a hablar de cosas más concretas.

Aquello que todavía no debemos, con el tiempo costará muy caro
- Nehuen Tupac Covelo Duran

Cuando vamos a desarrollar algún proyecto, vamos a intentar reutilizar la mayor cantidad de componentes, o sea hacer 1 vez cada UI para no tener que repetir código, reglas, estilos, etc.; evitando principalmente mantenimiento de código repetido. Y en componentes primitivos es fácil realizar eso(botones, inputs y links entre otros). Y de eso hasta podemos subir un nivel más, hacer los componentes más complejos(tablas, formularios, layout, etc). Pero empieza a complicarse mucho la cosa cuanto más vamos subiendo de nivel, por ejemplo a nivel de página; porque queremos abstraer el componente de una página? ¿Cuál sería el sentido de eso? Y justamente en estos puntos, cuando llegamos a componentes muy macros, es donde hacer sobreingeniería hace estragos. Y voy a dar el ejemplo más burdo y conciso en mi experiencia para que entiendan mi punto:
En una página de detalle de una película se debe bajar la información de esa película, y si el usuario tiene información guardada de esa película, lo cual todo debería venir en el mismo paquete de datos. En la pantalla se refleja si el usuario la agrego a favoritos, y si hubiese empezado a verla, un tiempo para reanudar la reproducción.
La lógica para cargar esto sería solamente bajar esos datos y guardarlos en un estado que luego se encarga de mostrarlo, si alguna cosa fuese modificada, tan solo mandar al backend la modificación. Es un flujo simple sin problema, haríamos una función handler para cada cosa, y estaríamos bien(obviamente podemos agregar una capa de servicios para no tener ciertas reglas en la UI y etc.).
La realidad del proyecto era totalmente diferente, alguna persona tuvo una idea de hacer un frontend que recibe una configuración de cómo son las páginas, eso va a mostrar condicionalmente los componentes de la página, cada componente de página va a generar un store interno para controlar los datos, y depende los datos que cambien a veces vamos a tener reglas que se encargan de mandar al backend depende las condiciones. Todo esto fue pensado con la idea de que haya un backoffice que deje a personas del equipo de Producto cambiar disposiciones y layouts de las cosas, pero resulta que nunca fue el objetivo real de la demanda solicitada. Entonces el resultado fue un frontend muy complicado de mantener con el tiempo, porque cambiar una condición en una regla de negocio podía romper todo muy fácilmente.

Y en este punto recuerdo mi frase; esa feature que nadie utilizó les costó un mantenimiento muy caro a los desarrolladores algunos años después. Porque no es el hecho de que el código se fue ensuciando y complicó el mantenimiento. Sino que el proyecto mal estructurado, para algo que no era el objetivo final, ayudó muchísimo en esa transición para que se torne una bola de código pegada por voluntad divina.

Otro gran problema de sobre-abstracción, cuando vamos a desarrollar componentes, es querer embutir reglas de negocio sobre componentes UI. Por ejemplo, un Input específico para validar documentos. Este componente además de cumplir su función como Input de datos, va a tener embutido una lógica con un regex, que si lo ingresado es incorrecto deberá dar un error de algún tipo. Pero qué pasa si se solicita que haya una validación para documento tipo DNI, pero otra para pasaporte? Y peor aún si tenemos que cambiar el texto de error devuelto, o si tenemos que hacer diferentes comportamientos: que muestre un mensaje simple, que abra un modal con una explicación de donde encontrar ese número correcto, etc. Tendríamos que hacer varios componentes particulares para cada caso, o generar un súper componente que logre recibir todo este tipo de variables, desde un mensaje de error diferente, hasta un tipo de validación diferente.
O lo que es más simple, más fácil, más entendible a nivel codigo: Que un componente Input(lo más headless posible) reciba la validación a través de una propiedad, por lo cual recibiría una función, y el accionar del flujo de error que va a percibir el usuario esté en la misma implementación. Si lo aplicamos, en cierto punto se ve muy simplista, y al ojo que le gusta abstraer todo puede no gustarle, pero créanme que con el tiempo ese código es mucho más fácil de entender y mantener.

Voy a explicar el ejemplo de un proyecto que nos pareció muy simple, tanto en implementación como desarrollo, y terminó siendo más que completo. Era necesario generar plantillas de emails de alguna forma dinámica, porque hacerlos a mano no era una opción debido a la cantidad de tiempo que demanda. Para esto creamos un pequeño proyecto basado en Pug.js, donde levanta un server en local para que se pueda hacer una preview de la plantilla necesaria, y luego un pipeline para hacer deploys, que lo único que hace es build de las plantillas y guarda los html resultantes en un S3 de AWS para que sea utilizado por el backend al momento de enviar los emails. Y la estructura de las carpetas se divide principalmente en dos carpetas, la de templates y components. En components encontramos todos los componentes(mixins en Pug) listos para usar, que reciben algunos parámetros de lo que tienen que mostrar y ya con todos los estilos listos. Y la carpeta templates contiene la definición de cada uno de las plantillas que sean necesarias, y esta carpeta es muy clave para la gente que no es del ámbito frontend(Backend, Growth, Producto, etc), porque todas las plantillas quedan escritas totalmente en la sintaxis de Pug que es muy parecido al markdown, y es entendible para cualquiera. De esa forma nos encargamos de crear los componentes base, y cualquier persona puede armar y desarmar esas plantillas sin necesidad de nuestro foco o ayuda.

La funcionalidad y el mantenimiento del proyecto nunca debería estar condicionada por la complejidad de la estructura del mismo.

Otro problema muy común en donde hacer sobreingeniería, es cuando las problemáticas y demandas no están definidas, o 100% cerradas. Y es un caso muy común en las startups, donde el PMF(Product Market Fit) no está totalmente consolidado y las reglas de negocio pueden cambiar a cualquier momento. Para lo cual hay un tipo de proyecto que se adapta a esas situaciones, el famoso MVP(Minimum Viable Product), el cual siempre debe ser descartado luego de un tiempo para ser reemplazado con un producto más robusto. Pero este tipo de proyecto no siempre cumple su ciclo de vida como debería, y el MVP con el tiempo se convierte en el producto final(arrastrando mucha deuda técnica); o donde el MVP nunca termina de salir a producción porque nunca está perfecto. Aunque una buena parte de mi experiencia sea en startups, no voy a ahondar mucho en esta parte, pero solo para cerrar: los MVPs deben ser proyectos muy simples, nada complejos, que puedan ser descartados fácilmente porque no representan un costo considerable de desarrollo.

Una moda en estos últimos tiempos, que es un claro ejemplo de sobreingeniería, fue la de promover hacer los frontends basados en DDD(Domain Driven Design), e implementando algún tipo de arquitectura como la Hexagonal. Todo esto es muy lindo cuando se dan algunas condiciones:

Tenemos una clara definición de los dominios
La capa de infraestructura no domina, ni define reglas de negocio, al interior de los dominios
Sabemos cómo implementar algo así en Frontend

Hasta ahora, nunca vi ningún proyecto(laboralmente) que cumpla esas condiciones. Y puedo asegurar, que intentar implementar este tipo de cosas sin darse todas las condiciones es un fallo asegurado. De alguna forma la implementación va a fallar, sea porque la infra va a imponer reglas de negocio sobre las nuestras, o porque ni siquiera tenemos una idea de cómo organizar esto para que tenga algún tipo de sentido y sea mantenible con el tiempo.

Todos estos puntos y otros, contribuyen no solo a la mala organización y difícil mantenimiento del código, sino también a la mala experiencia de desarrollo que deban sufrir la gente que entrara nueva. Se deberán encontrar con código que en sí mismo no atiende a la demanda y/o problemática, difícilmente entendiendo que es lo que hace y qué cosas se pueden sacar sin que explote el proyecto.

Decisiones escalables, no se trata solo de crear tareas

Nehuen Covelo — Wed, 27 Sep 2023 15:48:45 +0000

Artículo de la serie ¿Que es escalable?, Y que lo es en el desarrollo frontend?.

Foto de Scott Graham en Unsplash

Este tópico lo quiero dedicar a la decisión que se toma sobre las tecnologías a utilizar en los proyectos, que suele llevar más trabajo escribir las tareas de implementación, que el de estudiar y fundamentar porque vamos a usarlas. Por ejemplo: que funcionalidad nos provee?, porque tiene sentido dejar esa dependencia a cargo de una librería externa y/o porque tendríamos que desarrollarlo in-house. Yo me siento muy apasionado por esta parte, ya que realmente disfruto mucho del hecho de pensar cuales serían las mejores opciones para llevar a cabo cada proyecto. He tenido la suerte de que en más de una ocasión tuve la posibilidad de hacer esta selección y en todos los casos con un estudio por detrás de porqué escogí cada una.
Cabe mencionar que a pesar de siempre poner mucho empeño en elegir el mejor stack tecnológico a la hora de empezar un nuevo proyecto, también presencié muchos desastres en este sentido. Y con esa breve introducción advierto que esta sección puede ser omitida por aquellos que no estén tan interesados, no se sientan interpelados, o tan solo sean totalmente escépticos en la decisión del stack tecnológico en sus proyectos/trabajos.

Me he encontrado que muchas personas no les importa cómo queda la estructuración del stack tecnológico; y también he encontrado algunas personas que siempre están en la búsqueda del stack perfecto, que sirva para todo y que se pueda usar para cualquier situación o problema. Hago un llamado de atención aquí, porque no existe el stack perfecto como tal, que pueda abarcar todas las problemáticas. Existen algunos frameworks/librerías que apuntan a eso, por ejemplo Next.js, pero aun así a veces termina siendo una solución muy grande, pesada y costosa para desafíos que no presentan tal necesidad.
Un ejemplo rápido para entenderlo sería si: necesito hacer un panel administrativo, con autenticación para todas las cosas, y será usado principalmente para que el personal interno pueda acceder a datos de clientes mientras habla con ellos. Yo no creo que ninguna de las prestaciones fuertes que ofrece Next.js sirva para resolver esa problemática(SSR, embedded API, SSG, etc.); en cambio crear una simple SPA hecha con Vite (o cualquier librería/framework similar)reduciría costos, complejidad de desarrollo e infraestructura necesaria.
Y eso es solo un ejemplo hablando del framework/librería base que se encarga de las cosas más globales(enrutamiento, compilar el código, infraestructura que demanda, etc.), pero no voy a profundizar mucho en los aspectos de la relación "problemática vs stack tecnológico" (más adelante en este artículo hablo más sobre las librerías de componentes de UI y manejo de estado), y voy a continuar mostrando otra importante relación, el "capital académico vs stack tecnológico".
Digamos que tengo mi equipo de desarrolladores, y la mayoría de ellos tiene experiencia principalmente con tecnologías basadas en React. Pasaría por la cabeza de alguna persona cambiar el stack tecnológico para Angular/Vue? Sabiendo que muchos de los desarrolladores van a necesitar un tiempo de capacitación en esa tecnología que no tienen experiencia, ¿La empresa/el equipo puede permitirse ese tiempo de capacitación? ¿Los desarrolladores impactados por esta decisión (o al menos la mayoría), realmente están cómodos con ese cambio abrupto de stack?
Esas mismas preguntas las podemos plantear para casi cualquier cambio de tecnología en el ámbito que sea, algunas tendrán poco impacto, porque capas sean similares entre sí(ejemplo: styled-components y emotion); y otras tendrán mucho impacto(ejemplo: React vs Angular vs Vue, Zustand vs Redux vs Mobx). Ese impacto será desde código de mala calidad por no tener experiencia, hasta desarrolladores renunciando porque no se sienten cómodos ante estos cambios. Y estas situaciones que parecen distópicas, donde los cambios llevan a destruir el grupo de trabajo, son más comunes de lo que creemos, y yo encuentro una causa muy clara en estos casos.

Es casi costumbre que el stack tecnológico debe ser definido por personal "idoneo", como si los desarrolladores no tuvieran idea de lo que realmente es mejor para un sistema. Por eso muchas veces las empresas optan por delegar estas decisiones a equipos que trabajan solo para tomar estas decisiones de tecnologías, ajenos totalmente al desarrollo en sí mismo.

Entiendo que hace algunos años esos equipos tenían una buena reputación, porque eran como los que tenían la "posta" de lo que funcionaba. Pero eso no es lo que se ve reflejado en el presente de las empresas que conozco y/o que recibo comentarios. Y en mi experiencia solo me encontré que estos equipos hacen propuestas con stacks tecnológicos que encontraron en un blog o que ya funcionó para otro proyecto, donde modifican un poco la estructura para que sea más "escalable" a su manera y listo, descartando totalmente el contexto de los equipos que fuesen a ejecutar y desarrollar sobre esas tecnologías.
Con esto podríamos imaginar y recrear la situación más distópica para un equipo de desarrolladores, porque ahora el desarrollador debe agarrar ese stack que alguien más decidió por él (que a veces ni tiene experiencia en alguna de sus partes), adaptarlo para la problemática que tenga que resolver, que a veces tendrá que hacer alguna cosa extraña para resolver algún gap entre el stack y las reglas de negocio pautadas. Tendrá que seguir un diseño, y el design system que pusieron en el stack tecnológico probablemente tenga que ser modificado para poder alinear con lo que se pide. Y si ninguno de los desarrolladores tiene experiencia suficiente en alguna de las tecnologías usadas, probablemente las primeras versiones tengan algún problema de performance o poca calidad en la escritura de su código.

Con esto quiero hacer entender como una mala decisión de las tecnologías puede repercutir tanto en la calidad final del proyecto como en el equipo que lo desarrolla. Y no es mi intención criticar o definir quién debe ser el encargado de elegir las tecnologías a utilizar, pero si estoy muy a favor de que el mismo equipo encargado del desarrollo sea quien tome esas decisiones. Como situación utópica con la que me siento más cómodo(como desarrollador), es que las tecnologías sean elegidas por los programadores, que luego tendrán que utilizar ese stack, sabiendo cuales son los campos de experiencia y especialidad del equipo, obviamente sin perder la objetividad al momento de elegir un stack que sea moderno, porque que haya desarrolladores que hayan tenido mucha experiencia y les sea familiar jQuery, no puede ser tomado como fundamento, bajo ningún punto de vista, para elegir jQuery como tecnología hoy en dia.

Para cerrar esta idea voy a dar un ejemplo donde tuve que elegir las tecnologías para el proyecto de un e-commerce. Era necesario tener obviamente un buen SEO, para que los productos sean indexados en los motores de búsqueda, y eso era lo principal. Para esto elegimos Next.js, usándolo con server side rendering ya que la plataforma en ese momento tenía más de 10 mil productos. Una de las decisiones más difíciles de plantear fue si íbamos a trabajar con Javascript plano o Typescript. Parece algo raro preguntarse eso actualmente, pero voy a explicar a qué venía esta incertidumbre. Para desarrollar este frontend, con objetivo de dejar de utilizar la plataforma Shopify, teníamos 8 personas en el equipo y muy poco tiempo, el deadline desde el kickoff del proyecto eran 2 meses. De esas 8 personas, solo 3 teníamos experiencia en Typescript, las otras 5 personas iban a tener que empezar a aprenderlo, y además aprender otras tecnologías como GraphQL, el entorno de Next.js(no era ampliamente adoptado en ese momento); y como frutilla del postre también desarrollar el design system que iba a utilizar nuestro front end. Poniendo todas las cosas en la balanza, decidimos que Typescript solo iba a complicar y retrasar las cosas, entonces decidimos seguir con Javascript plano. Fue una decisión correcta, y llegamos a entregar lo prometido a tiempo, después por otras cosas se retrasó el release en general, pero fue ajeno a nuestro contexto. Tiempo después de esto, recibí muchísimas críticas de nuevas personas que fueron sumándose a la empresa, diciendo que había sido la peor selección de tecnologías que una persona pudo haber hecho. Esos comentarios en su momento me afectaron bastante, pero lo superé con el tiempo ya que esas personas lo dijeron desde la ignorancia total, ellos ya tenían un equipo con un Seniority muchisimo mas alto del que yo tenía en su momento; y nosotros además teníamos un deadline super apretado para entregar todo un ecommerce de 0 funcionando.
Pongo mi ejemplo para que no solo sepan cómo elegir las tecnologías en base al conocimiento que hay en el equipo que va a encargarse del desarrollo, sino también para que no hagan una crítica destructiva sobre cuáles fueron las elecciones de esas tecnologías si desconocen el contexto del momento en que las eligieron. Aunque sí sugiero que vean cuales son las posibilidades de mejora que tienen esos proyectos.

Ahora voy a entrar en algunos temas que puede generar algo de controversia, las librerías de componentes UI y las de manejo de estado. Y digo que puede generar controversia porque las librerías más populares del mercado actualmente no me parecen para nada útiles a la hora de pensar en un proyecto escalable, y obviamente daré mi punto de vista para que se entienda.

Primero vamos a ver los componentes de UI, y algunas características que yo veo muy importantes a la hora de elegir una librería de componentes:

Debe tener un naming convention que se respete a todo momento, tanto en los nombres de los componentes, como en sus propiedades, eventos, etc.
Debe tener algún sistema de theme que permite customizar estilos generales del mismo, colores, espacios, etc.
Tiene que ser compatible con las otras librerías sin necesidad de estar haciendo workarounds para funcionar. Por ejemplo con Typescript, con Next.js y su SSR, con el bundler(Webpack, SWC, es-build), etc.
Debe respetar los estándares de accesibilidad.
Una documentación clara.
Que al implementarlo no sea como ensuciar el código, quitando legibilidad, siendo poco intuitivo.
Que la curva de aprendizaje sea baja, no tiene que representar un desafío usarla.
Es obvio, pero que no tenga errores, que no represente un riesgo utilizarla.
Debe tener una variedad de componentes considerable; si tiene pocos podríamos necesitar instalar otras librerías para complementar, lo cual podría terminar generando inconsistencias en los estilos.

Y la mayoría de estos puntos no son siempre características de las librerías más adoptadas, y voy a poner como ejemplo MUI(Material UI), que para muchos es la mejor librería de componentes, y en mi experiencia es muy deficiente. Pero antes de comenzar a mostrar todo eso, voy a dar el contexto de la creación de MUI y porque la librería que se ofrece al mercado es tan solo un parche de la versión inicial.
Google lanzó su librería MUI en 2014, escrita plenamente en Javascript para usarla con React, al momento de escribir esto son casi 9 años. La versión 5 salió en septiembre de 2021, y ya encontramos algunos red flags desde mi perspectiva:

La librería sigue teniendo el 50% de su código en Javascript plano.
Entre las pocas razones para hacer la versión 5 encontramos que fue para que la librería sea compatible con las últimas versiones de React, porque tuvo muchos problemas de compatibilidad, y encontramos que aun así cuando salió tuvo muchísimos issues abiertos, principalmente debidos a la compatibilidad con React.
Entramos a los issues en Github y vemos que hay muchos, realmente muchos issues abiertos y categorizados como "bugs".

Ahora, todos esos puntos no serian tan pesados si habláramos tal vez de un proyecto Open Source, pero encontramos que MUI está siendo mantenida por Google, y que además tiene una versión paga donde tiene la colección completa de componentes. Y para agregar un punto más a la lista, si intentaron usar los componentes de DatePicker, que solo están disponibles pagando la librería, funcionan muy mal, las traducciones a idiomas como el Portugues está mal hecha, la accesibilidad es dudosa y en algunos casos desastrosa, y ni siquiera podemos cambiar la variante de estilos del componente (con la propiedad "variant") cómo se podría hacer con cualquier otro componente de input dentro de MUI. Y ni siquiera voy a entrar en cuestiones UX donde hay varias críticas al sistema de label flotante que utiliza, el cual puede generar confusión y dolores de cabeza en formularios largos.
Entonces todo este contexto junto solo muestra que la librería que hay actualmente, es tan solo un parche encima del otro de lo que fue la versión inicial de la misma, con el objetivo de intentar "adaptarse" a las nuevas versiones y tecnologías en auge.

Ahora la gran pregunta que surge después de plantear todo esto, ¿Y entonces qué elijo? Actualmente hay más variedad de librerías, en su mayoría Open Source, que cubren una buena parte de las necesidades que tenemos a la hora de elegir una librería de componentes UI. Yo voy a dar una lista de ejemplos de librerías actuales que traen una lavada de cara a la mala fama que existe sobre las mismas(me gustaria ampliar en número, pero estan son las que tengo en mente ahora mismo):

Mi intención no es que elijan de esa lista, pero sí que vean lo que ofrecen de mejoras ante la supremacía de las librerías más establecidas en el mercado, con alto número de descargas y uso.

Ahora pasaré a las librerías de manejo de estado, donde voy a decir que el uso de la más conocida es tan específico que es muy fácil reemplazarla con otras opciones, que no sean tan complicadas y abstractas. Y de la misma forma que hice con las librerías de UI no voy a entrar tanto en la cuestión de código, porque eso no pertenece al tópico de este artículo sino a uno de los próximos donde voy a hablar específicamente de eso.

Yo ya estoy siendo consciente de varios de los comentarios que tendré que leer, "Vos porque no entendes como funciona Redux, entonces decis cualquier cosa". No busco justificar mi posición, pero sí comentar que ya tuve que trabajar con Redux, y con Redux Toolkit más recientemente, y en ambas ocasiones tuve que estudiar bastante a fondo para entender cuál es la finalidad y la filosofía por detrás de Redux. Realmente lo veo como un mal necesario cuando llegamos a un proyecto tan grande que haga falta un increíble motor para manejar los estados, y el único/mejor ejemplo que se me ocurre es una arquitectura con micro-frontends. Y fuera de ese ejemplo, la arquitectura necesaria para micro-frontends, Redux es un overkill, sobre ingeniería y abstracción muy grande. Y en ese momento hay que poner en la balanza si el proyecto será desarrollado por gente con el seniority suficiente como para entenderlo, porque con el tiempo se empieza a ver la complejidad que agrega tener un manejo de estado abstraído en Redux.

Entonces es realmente importante saber: ¿Qué tan necesaria es esa capa de abstracción que agrega Redux?, ¿Mi proyecto realmente lo necesita?
Piensen que crearon Redux Toolkit a modo de simplificar la implementación del mismo Redux porque es muy complejo de entender, y aun así la gente más Junior no logra descifrar que es lo que hace. ¿No hay otra solución que sea más simple y de las mismas prestaciones?
Fijense que Redux es opinionated(que tiene una sola forma correcta de usarlo, lo demas esta mal), ¿Voy a tener que adaptar siempre mi estructura al manejo de los estados?, ¿No existe al revés, el manejo de estado que se adapta a mi lógica de negocios, a mi estructura, arquitectura?.
Y si, existen otras alternativas a Redux, y voy a nombrar las que seguramente ya escucharon:

Zustand
createContext(nativo React)

Aunque createContext este atrelada a React, es una gran solución para cuando el proyecto no es muy extenso. Para los que lo hayan usado, sabrán que una vez que el manejo de estado empieza a ser muy complejo se complica mucho mantener los contextos. Pero para un proyecto chiquito, con un manejo de estado más simple, es asegurado que va a servir muchísimo.

Pero la librería que más me ha llamado la atención fue Zustand, justamente surge casi como la contra parte a Redux, ofreciendo un manejo de estado que lo podemos adaptar a nuestro entorno de desarrollo, sin tener que seguir las reglas paso a paso y evitando copiar y pegar sin entender lo que hace. No lo quiero plantear como una crítica a Redux, pero al final lo termina siendo. Además, ofrece una simplicidad mucho mayor en la abstracción de los stores, casi que no se siente que sea una capa ultra separada de todo, que no se toca con el código UI que implementamos.

Al momento de escribir esta parte vi un meme que dice "Todos hablan de la experiencia de usuario, pero nadie piensa en la experiencia del desarrollador", y aunque fuese tan solo un meme todo esto lo pienso de esa forma. Que el proyecto tenga una armonía entre sus partes, con una buena elección de tecnologías, siempre ayuda a que la experiencia de desarrollo sea mucho mejor y hasta en cierto punto placentera. Y todas estas elecciones las tendríamos que hacer siempre que vamos a empezar un nuevo proyecto? Si, pero no es una posibilidad que exista en general, y muchas veces cuando la posibilidad está abierta, el tomador de decisiones ya tiene un paquete elegido. Eso no quiere decir que siendo simples desarrolladores no puedan aportar a esas decisiones. La idea es siempre uno poder llevar la impronta de algo nuevo, moderno o hasta de cuestionar las decisiones, preguntando ¿porque esto y no aquello?

Mi idea en este tópico fue que se haga hincapié en los temas que los hype, modas, tendencias o como quieran decirle, tienen ya seteados como default en nuestro sentido común; por ejemplo que si quiero hacer un frontend usar Redux y MUI va a ser una decisión totalmente válida para cualquier situación, cuando realmente no es así. A veces, estas cosas pueden ser muy obvias para alguien que ha tenido años desarrollando con varias tecnologías, y puede observar estas diferencias de prestaciones que ofrece cada tecnología, pero una persona sin tanto tiempo en el rubro podría confundirse fácilmente por no hacerse las preguntas correctas al momento de elegir.

Comunicación escalable, esto no es solo código

Nehuen Covelo — Wed, 20 Sep 2023 13:35:59 +0000

Foto de Nick Fewings en Unsplash

Artículo de la serie ¿Que es escalable?, Y que lo es en el desarrollo frontend?.

En este articulo voy a hacer una crítica de la forma en que nos comunicamos, y lo que suele ser "normal" en el grupo de trabajo. Y para ellos voy a empezar dando un ejemplo de una situación típica, cuando ocurre un error en producción, y tenemos que explicar lo que está pasando a través de mensajes.

Si tenemos que comunicarnos con alguien que no es de IT, diríamos algo como:

Los usuarios no estaban pudiendo realizar acciones en la plataforma porque debido a un error introducido en la última versión lanzada la autorización al solicitar cualquier cosa no se estaba haciendo.

Y entonces lo "normal", o lo que estaría "bien", es llevar todo eso a un nivel más técnico para hablar con otros programadores:

Cuando el usuario autenticaba, se dejó de guardar el token necesario para la autorización de los servicios, porque el contexto donde se controla eso fue modificado debido a una tarea donde era necesario salvar otro dato que no teníamos.

Esto representa que tenemos que escribir más de un tipo de mensaje, uno para explicarlo a gente ajena al desarrollo un stakeholder por ejemplo, capaz habría que explicar también para un PM/PO(que va a querer además datos de impacto: tiempo de servicio out, usuarios afectados, pérdidas, etc.), y todavía tendríamos que hacer una explicación más con tal de explicarlo a nivel técnico(que generó el problema- commit, LOC, whatever -, propuestas para evitarlo en el futuro, etc.). Todo esto pensando que lo estaríamos haciendo en problemas grandes, en errores que son bloqueantes al usuario. Si además todas estas explicaciones en todas sus variantes lingüísticas habría que hacerlas para cada uno de los bugs que se encuentren en el día a día, podría apostar a que todos los días se irían solo escribiendo explicaciones.

¿Creo que es necesario dejar de dar tanta explicación? No, pero creo que podemos hablar en un vocabulario más general entre todos, y entrar en un detalle técnico solo si fuese necesario o pedido específicamente porque alguien quiere entender más a fondo el problema.

Usando el primer tipo de mensaje que puse como ejemplo(que apunta a un público ajeno a IT), una persona que también es programador entendería a grandes rasgos qué fue lo que pasó, ¿no? En mi cabeza pasaría algo así como "para autorizar las llamadas al backend entiendo que tenemos que mandar algun tipo de token, debe ser alguna cosa relacionado a eso".
Ahora veamos el caso que más me interesa mostrar. Tomamos el segundo mensaje(con un vocabulario más tecnico), y cuando lo va a leer una persona que también programa, pero no sabe de qué trata el proyecto del que se está hablando, porque todavía no participó o porque es alguien de otro ámbito(Backend, QA, DevOps, etc.), ¿hasta qué punto esa persona va a entender de lo que se está hablando?
Por ejemplo, ¿la persona va a saber lo que es un contexto?(siendo un concepto atrelado fuertemente al desarrollo frontend) ¿esa persona va a saber a que servicios hace referencia?

Entonces, ¿hasta qué punto tiene sentido perder tiempo comunicando cosas a nivel técnico, que precisan de un vocabulario que sólo tiene pleno sentido para una reducida parte del equipo?
Con esto no quiero que se me malentienda y piensen que yo digo que entonces no hay que hacer documentos como los Post Mortem; creo que tienen mucho sentido cuando son problemas realmente graves (major/total outage, un hackeo), pero he trabajado en organizaciones donde se hace un post mortem cada 2 dias porque se exige explicar hasta el porque el color de los botones no está alineado con lo que fue diseñado(Big Red Flag).

Otro tema que quiero abordar en la comunicación, es a la hora de escribir tareas. He estado en empresas que se utiliza muchísimo tiempo solo para escribir las tareas, y el problema reside principalmente en dos cuestiones:

Falta de definición de lo que es realmente necesario hacer, sea regla de negocios o falta de claridad en el flujo.
Querer adelantar lo que se debe hacer a nivel código para realizar esa tarea.

El primer punto no lo vamos a abordar, creo que es algo obvio que nos excede como desarrolladores que las decisiones de negocio o diseño no estén consolidadas. Pero obviamente quiero enfocarme en el segundo, que es un error muy tonto solo de pensarlo, pero que suele ser algo super comun de hacer durante las planificaciones. Y es normal que cuando nos digan "Hay que realizar X modificación en el flujo Y", ya tengamos una idea de lo que tenemos que hacer, si es que tenemos el conocimiento sobre el proyecto para realizarlo. Pero no por eso va a ser necesario que hagamos una transcripción de eso en la tarea, porque puede ser que:

Lo simplificamos demasiado a lo que realmente es.
Es otro el que lo va a hacer y no entiende de que se está hablando.
El código que tenemos en la cabeza ya no es como pensamos, en el medio puede que hayan sucedido varios cambios.

La forma de evitar cualquiera de esos puntos es fácil, literalmente ir al código y comprobar todo eso, ¿no? Claro que sí, pero ¿no seria mas facil ya ir al código y resolver la tarea también, para evitar el context switching? Si, obvio que si, pero al mismo tiempo sería un desastre la organización general de las tareas; es un caos en sí mismo.
Entonces, ¿Qué hacemos? Dejamos la definición de las tareas lo más simple y explicativo posible, sin entrar en terminos muy tecnicos(a menos que sea realmente necesario), y en caso de necesitar ayuda por falta de conocimiento, o porque no entendemos la demanda, es tan solo enviar un mensaje a alguien o un grupo de personas que nos pueda auxiliar.

Todo esto parece un poco contradictorio en sí mismo, pero quiero dejar un ejemplo muy claro y evidente para que se logre entender la pérdida de tiempo que genera la sobre definición de las tareas.

Se necesita cambiar los brand colors de la aplicación, tal como se definió en el diseño. Link al diseño

Se da una mirada al diseño y creo que ya todos más o menos tendrían una idea de lo que se debe hacer, ¿no? Pero es más que común la situación, donde de esa tarea se realizan refinamientos(de los cuales hablaré más en el tópico de organización) y quedan tareas definidas así:

Se necesita cambiar los brand colors de la aplicación, tal como se definió en el diseño. Link al diseño
Para eso es necesario modificar en el theme del proyecto todas las propiedades brand tal cual definidas en la configuración del diseño system que está en el diseño.

¿Eso sirve? Si, y probablemente el que realiza la tarea, si lo lee, pueda resolverlo más rápido. Pero para hacer esa explicación de como resolverlo tuvimos que gastar un tiempo más en explicarlo, cuando tendría que ser algo que ya tendríamos que saber a priori al momento de leer la definición general de lo que es necesario hacer en esa tarea. Y como dije antes, en caso de no saber como resolverlo, es tan solo pedir ayuda para que nos expliquen por donde mirar.
Entiendo que hay mucha gente que no concuerde en este punto, pero yo no concuerdo en la perspectiva, casi moda, de ser ultra explicativos, teniendo que escribir las definiciones de las cosas como si el receptor de las mismas fuese una persona ajena al contexto del desarrollo. Obviamente que esto no aplicaría a gente muy Junior, o gente que está en proceso de onboarding, pero también no voy a explicar hasta lo último que debe hacer porque entraríamos a criar Juniors eternos, o un onboarding de nunca acabar.

Y como dije al principio, no voy a ofrecer una fórmula mágica para llegar a mi punto de vista ideal de esa comunicación, cada equipo, empresa y producto es un mundo diferente, con dinámicas diferentes, con exigencias diferentes y sobre todo con personas diferentes.

¿Que no es escalabilidad? El sentido común de lo que es escalable

Nehuen Covelo — Wed, 13 Sep 2023 13:24:47 +0000

Foto de Artem Maltsev en Unsplash

Artículo de la serie ¿Que es escalable?, Y que lo es en el desarrollo frontend?.

Hoy en día el término "escalable" se usa en cualquier presentación (de forma totalmente vacía en la mayoría de las ocasiones) para referirse a cómo se caracteriza un producto, sistema y/o aplicación. Pero, ¿realmente sabemos lo que significa? Buscando rápidamente su definición en Google o en algún blog, obtenemos que "incluye componentes chiquitos, customizables, de fácil mantenimiento, independientes entre sí, que sean fáciles de implementar" o también que "la escalabilidad estará dada en su capacidad de crecer y adaptarse a los cambios según la demanda". Son ideas realmente simples, súper universales y que nadie esperaría menos que eso, pero me surgieron las siguientes preguntas: ¿es eso lo que busco al plantear un proyecto escalable? ¿tan solo intentando abstenerme a esas dos definiciones mi proyecto va a ser totalmente escalable? Encuentro que la respuesta es "No", a menos que el proyecto no lo va a tocar nadie más, e ignoro un montón de otros factores importantes a la hora de trabajar en un equipo.

¿A qué quiero llegar con esto? Voy a dar un algunos ejemplos para que quede más claro:

Una buena documentación, que facilite la comprensión y onboarding del proyecto, no sería parte de ese concepto de escalabilidad. Dando solo un readme con los requisitos y pasos para usar el proyecto de forma local, lo podría probar cualquier otro desarrollador sin tener conocimiento y contexto del mismo.
Creo un proyecto usando una estructura de carpetas que saqué de un post/video muy reconocido (o la invento yo mismo) y es súper escalable porque "lo usan todos" (amo, y odio con mi más profundo ser ésta frase como fundamento para decidir cosas). Luego de un tiempo, como nadie lo revisó porque es algo que "lo usan todos", encontramos que la mayoría de los desarrolladores no logran entender muchos aspectos de esa estructura, en muchos casos se empieza a cuestionar y solicitar cambios, perdiendo así muchísimo tiempo.
Los componentes tienen siglas en los nombres, como por ejemplo NBCForm, BDEPopup, MDPage; y cuando ingresan nuevos desarrolladores se necesitará hacerles una introducción y un glosario para que entiendan lo que significan. Esto no es nada escalable, porque esa persona tiene un proceso donde va a tener que memorizar cada una de esas siglas, y en caso de tener un glosario perderá mucho tiempo yendo a buscar sus definiciones. Esto se podría facilitar al nombrar los componentes sin siglas, NewBatchCustomerForm, BillingDetailEditPopup, MovieDetailPage. Los nombres quedarán más largos pero es literal y entendible lo que hacen.
Ejemplo de una aplicación supuestamente escalable: "El frontend es escalable porque la estructura de las páginas de la aplicación está configurada desde un backoffice que cualquiera de Producto puede usar. Pero Producto nunca lo usa porque en realidad nunca fue una demanda". Entonces hubo una complejización del proyecto muy grande para atacar una demanda que nunca existió.

Que copiemos o creemos un proyecto escalable a nivel código/infraestructura, no significa que va a sobrevivir en un entorno no escalable. Y con esto me quiero referir específicamente a que la escalabilidad del proyecto, la capacidad de adaptarse a los cambios según la demanda, no será dada sólo porque el código que escribamos sea de calidad (obviamente que esto también importa, no lo pongo en duda), sino que el entorno en el cual se desarrolla debe acompañar esa escalabilidad.
Para definir lo que no es escalabilidad, me gustaría seguir dando ejemplos y descripciones, porque a veces lo mejor para definir un concepto tan amplio es muchas veces mostrar lo que no es, pero tampoco es mi objetivo escribir una extensa crítica a lo que el común de las personas perciben por "escalable", pero si desmitificar.
Por lo cual yo definiría la escalabilidad de un frontend como:

Cuando se pueda adaptar a las demandas y problemáticas específicas que ataca nuestro proyecto.
Complejizar/abstraer aspectos que no sean relevantes a estas demandas solo resta escalabilidad. Estas abstracciones deberán ser mantenidas con el tiempo, y si no agregan valor se traduce en esfuerzo y tiempo derrochados.
Debe tener una curva de aprendizaje lo más facil y rapida posible, tener un onboarding de varios meses para cada nuevo desarrollador solo para que entienda la estructura base del proyecto es algo muy común y al mismo tiempo improductivo (no solo para el recién ingresado, sino también para aquellos que lo van a asistir durante el proceso).

Espero que si llegaron hasta aquí, puedan entender un poco más claro ese concepto de escalabilidad, agregando justamente una parte importante en su definición: lo que no es escalable. Entonces, creo que puedo dar por cerrado este tópico, habiendo intentado deconstruir un poco el termino dentro de nuestro rubro, específicamente de Frontend.

¿Que es escalable?, Y que lo es en el desarrollo frontend?

Nehuen Covelo — Wed, 13 Sep 2023 13:23:28 +0000

Photo by Jacopo Maia on Unsplash

Esto será la introducción a una serie de artículos que iré publicando relacionados principalmente a lo escalable en el ámbito del desarrollo frontend, apuntando al aspecto tecnológico, pero también a otros que estarán ligados a las relaciones y las situaciones en las que nos desenvolvemos como desarrolladores. Con estos artículos no tengo como objetivo final mostrarte una receta lista pero si ayudarte a preguntarte: ¿mi proyecto es escalable?, ¿las costumbres de mi equipo lo son?, ¿cuáles cambios son necesarios para lograrlo?.

Basados y redactados desde mi propia experiencia en el rubro, pero que surgen a partir de la moda de usar términos lindos- "fancy words" - vacíos de contenido, que en la mayoría de los casos no refleja la realidad de esos proyectos/equipos.
Para ello dividí esta serie en tópicos que harán un poco de guía en mi punto de vista de lo que es escalable, que servirán como deconstrucción del término "escalabilidad", ayudando a quitar el sentido común de lo que realmente significa. Estos artículos están intrínsecamente relacionados pero los redactaré lo más independientemente posible uno del otro para que facilite la omisión de los que no sean de interés para algunos lectores; por ejemplo todo lo relacionado a proyectos en equipo.

¿Cuál es mi objetivo con todo esto? Desmitificar un poco lo escalable, para dejar de utilizar el término sin realmente saber lo que es, y empezar a concientizar la importancia que un proyecto realmente lo sea. Y sobre todo en un ámbito como el desarrollo frontend donde lo escalable no tiene una forma muy definida y es borroso incluso para los más experimentados. No es para que nadie se sienta atacado por lo que digo, pero mucha gente al momento de definir el entorno en el que se va a trabajar omite preguntas muy importantes que se necesitan hacer antes de definir muchos aspectos; sean tecnológicos, de comunicación, de la organización, etc.
Para eso vamos a utilizar una estrategia, un tanto filosófica, definiendo lo escalable por lo que NO es. Y, ¿por qué iré por este camino? Porque iremos viendo que la escalabilidad depende de algunos factores como el modelo de empresa, del negocio, del equipo y hasta del capital humano con el que trabajemos. Igualmente intentaré dar varios ejemplos de lo que realmente no entra en la definición, independientemente de los factores y aspectos al interior de nuestro entorno, para que puedan obtener una imagen más clara de lo que yo logro ver como frontend escalable.

Algunas aclaraciones

Antes de comenzar quiero dejar asentado algunos puntos de la forma y lo que yo pretendo hacer llegar a la persona que lea esto.
Este es un punto de vista de la escalabilidad desde mi subjetividad intentando ser lo más objetivo posible, podes no estar de acuerdo en alguno o todos de los tópicos. Las preguntas que planteo están enfocadas principalmente a grupos de trabajo y quizás no sea la realidad para otros proyectos, por ejemplo Open Source, entre amigos, personales, etc.
Este artículo está enfocado específicamente a los proyectos frontend, pero estará buenísimo si algunas de las cosas las pueden tomar para otros desarrollos (Backend, QA, DevOps, por nombrar los ámbitos más conocidos). Justamente como dije al principio de este artículo, no vengo a plantear una fórmula/receta de como ustedes deben estructurar su proyecto/entorno de trabajo, pero si cuales son las principales preguntas que yo me haría al momento de intentar mejorar un proyecto nuevo o existente.

Índice

Organización escalable, como una mala rutina solo empeora las cosas

Nehuen Covelo — Mon, 11 Sep 2023 13:41:45 +0000

Artículo de la serie ¿Que es escalable?, Y que lo es en el desarrollo frontend?.

Foto de Fab Lentz en Unsplash

En este tópico voy a dejar un poco el lado critico, solo un poco, y enfocarme más en la recomendación de algunos hábitos para organizar de forma más eficiente, y también saludable, la vida laboral. Ire tanto a nivel personal, como a nivel laboral y organizativo de equipos, desde qué propuestas podemos tomar para mejorar nuestro potencial como desarrollador, pero también buscar la mejora de nuestro entorno.

Y empezando con el ámbito más personal, una recomendación básica es acostumbrarse a dormir en horas no muy tardes, y en lo posible despertarse temprano. Y digo "acostumbrarse" porque sé que no es un proceso en el que uno dice "A partir de ahora me voy a levantar temprano" y se nos regulariza el reloj biológico, lleva tiempo y a veces cuesta mucho. Y con respecto a eso, están circulando algunos estudios que dicen que nuestro horario biológico de sueño está definido genéticamente, por lo cual hay gente que le cuesta más levantarse temprano por genética. Entiendo la visión que traen estos estudios, pero recursos humanos no arma nuestros horarios de trabajo en base a nuestra disposición genética. Y como para la gran mayoría de los que trabajan en desarrollo, siempre suele haber reuniones por la mañana, por ejemplo la Daily. Entonces, levantarnos temprano de alguna forma u otra lo tenemos que hacer, pero acostumbrarnos a hacerlo puede ayudar a que no sea un proceso tan pesado.

Otra recomendación es no terminar de trabajar justo antes de ir a dormir, sino realizar alguna actividad antes, aunque sea tomar una ducha. Espero que nunca les haya pasado el famoso "en el sueño encontraba la solución de mi error", porque nunca es verdad que la encuentras, es tan solo una ilusión que genera el mismo sueño. Y en mi caso todas esas veces me despierto en mitad de la noche pensando que realmente tengo esa solución, hasta que entiendo que solo estaba delirando. Y es malo que se corte el sueño de esa manera, a veces podemos retomar el sueño, y otras tantas nos desvelamos sin poder conciliar nuevamente el sueño. Y justamente esto suele ser efecto de que nuestra conciencia no se desconecte del contexto de trabajo y continúa procesando cosas.

Recomendación muy repetida (pero que vale la pena recordar), es que cuando tengan tiempo libre, estudien alguna cosa nueva o de un contexto/ámbito/lenguaje diferente, sobre todo para quienes quieran reforzar sus conocimientos como desarrolladores. Cada trabajo nos da muchos conocimientos por los nuevos desafíos y problemáticas que cada uno representa, pero aun así esos conocimientos y conceptos son relativos a ese trabajo, por lo que ver y conocer otras perspectivas pueden ayudarnos a encontrar mejoras en nuestro propio entorno.

A nivel personal esas son las recomendaciones más fuertes que puedo aportar, porque al final de cuentas como desarrollador nos solemos desenvolver en un entorno de trabajo con otras personas, bajo normas y tiempos preestablecidos. Por lo cual los factores, que cambian nuestra rutina, son en su mayoría externos a nosotros. Y por eso, ahora hablaré sobre algunas recomendaciones que doy para la organización de los equipos de trabajo.

Las reuniones, parte fundamental de una organización escalable

Aquí pienso explayarme bastante sobre las reuniones, las cuales son en muchos casos beneficiosas, y en otros absolutamente improductivas. A pesar de que hoy en día ya haya tantos ejemplos de cómo organizar estas rutinas, las grandes empresas tienen en el día a día muchos problemas lidiando con esto. Y por eso voy a hacer una distinción entre dos tipos de reuniones, que las nombraré como reuniones de rutina y reuniones excepcionales.

Empezando por las excepcionales, que son las que menos detalles y críticas voy a hacer. Estas reuniones surgen a partir de una demanda específica, fuera de la rutina, por ejemplo:

Un bug crítico
Alinear una tarea muy grande
Solicitación de ayuda de un compañero

Para estas reuniones, primero tenemos que hacernos la famosa pregunta tan repetida (pero muy necesaria), "¿Esto se podría resolver con un mail/mensaje?". Porque hay que tener en cuenta que las demás personas implicadas, están trabajando en alguna cosa que puede no estar relacionada con lo que yo estoy haciendo, y estaría sacándolos del foco de la tarea que estén ejecutando. Y obviamente se debe tener en cuenta la urgencia del asunto, aunque exista mucha gente que parece no entender muy bien cual es la definición de urgencia.
Obviamente si estamos ante un major outage vamos a llamar por teléfono si es necesario a alguien para que pueda socorrer en esto, pero no antes sin tener un mínimo de contexto de lo que está pasando. Y rápidamente agregando a ese ejemplo encontramos un error muy frecuente. El famoso teléfono descompuesto, en donde al desarrollador le llega que la plataforma no funciona, está todo caído, pero en realidad lo que no funcionaba era un feature fuera de los flujos más críticos.
Realmente es necesario medir la frecuencia y necesidad de estas reuniones, porque tener personas sin hacer nada en una reunión (solo como oyentes) no sirve más que para distraerlos de sus tareas. Si realmente es una urgencia tenemos que tener una idea de a quién llamar, para evitar destruir la productividad en general del equipo.

Ahora, veremos las reuniones de rutina, que en la gran mayoría de los casos son reuniones derivadas de algún marco de trabajo como lo es Scrum, Agile, Kanban, o lo que sea. Y acá voy a parar un momento a hacer una crítica muy dura a lo que hacen en muchas empresas, que es seguir el librito del Scrum/Agile/Kanban/Pirulo Master como si fueran reglas invariables, donde hay una persona que su trabajo es velar por el cumplimiento de esos rituales. No estoy en contra de que haya un Scrum Master/Agile Coach o rol similar, pero no acepto que el marco de trabajo sea fijo y no tenga variación con las experiencias que va teniendo el equipo.
Y voy a traer un ejemplo fácil para entender porque no tiene sentido seguir todo siempre al pie de la letra lo que dicen estas prácticas:

Desde el backlog vemos que todas las tareas son simples cambios de UI, colores, bordes, etc. Todas ya están todas las tareas con puntos, porque se realizó una pre planning, está todo listo, y son tareas muy simples. (Después de esto realmente hace falta refinamiento?)
Se llama a todo el equipo de desarrollo para hacer un refinamiento, donde todos van a leer hasta las tareas que ni siquiera les van a asignar. Todo para chequear que todo esté bien escrito y se entienda. (Usamos 2-4 horas de todos los desarrolladores en cada sprint para hacer esto. ¿No se podrían revisar las tareas redactadas cada uno por su cuenta- cada desarrollador toma la revisión de X tareas -, sin necesidad de dejar de hacer la tarea actual?)
Llegamos a la retro del sprint, llevan estas inquietudes, de omitir los refinamientos cuando no sea realmente necesario hacerlos.
La respuesta que obtuve siempre fue un NO, hasta en algunos casos parecía que me trataban de loco, como si atentara contra la buena organización de la empresa. Otro ejemplo básico y que pasa con frecuencia, si una semana se llena de bugs y soporte, y la mayoría de las tareas planificadas para ese sprint quedan como carry over, ¿Tiene sentido hacer una hacer una planning?, ¿Hacer refinamiento de las tareas del backlog? Si vamos a hacer las mismas tareas que quedaron de carry over.
Y lo que termina pasando, es que si realmente es necesario hacer cada una de las reuniones que son propuestas en los enlatados de Scrum/Agile/Kanban estaríamos dedicando a todos los desarrolladores por lo menos 10 horas de reuniones por sprint(solo planning 2hs, refinamiento 2-4hs, retro 2hs, daily cada 1/2hora). Y estamos hablando sólo de las reuniones ligadas al marco de trabajo, no estamos ni siquiera tomando las reuniones de actualizaciones de la empresa, charlas con otros sectores, etc.

Un poco antes de escribir este artículo descubrí una buena causa que podemos atribuirle a la mala mala implementación que suele hacerse de los marcos de trabajo. Y entiendan que yo hablo del marco de trabajo, el cual es el término y concepto que le corresponde. Siendo un marco de trabajo un conjunto de herramientas que nos ayudará a abordar cierta problemática con mucha más facilidad sin tener que reinventar todo un sistema de organización de 0. Pero cuando vamos a la realidad de las empresas, ellos no hablan de marcos de trabajo, sino que usan el concepto metodologías agiles, y el problema que yo encuentro (como maldito aspirante a filósofo) es el mal uso de la palabra metodología.
Una metodología es una lista de pasos a seguir, como si fueran instrucciones, donde no podemos aceptar el cambio de orden u omisión de alguno de estos. Y darle el carácter de metodología, a lo que en realidad son marcos de trabajo, nos condiciona y obliga a usar enlatados de rituales, los cuales siempre "funcionan" y son inevitables, sin importar el más mínimo aspecto del contexto del equipo que lo lleva a cabo.

Aunque tengo una posición fuerte y encontrada contra la mala implementación de los marcos de trabajo, realmente creo que son muy útiles, y en la mayoría de ellos encuentro muy increible el ritual que suele llamarse "Retro"(Retrospectiva), donde justamente se busca que todos den su punto de vista sobre lo que se puede rescatar de buenas prácticas, y que podemos mejorar de lo que no salió tan bien. Aun así, he visto como en muchas empresas la Retro es muy bien ejecutada, dejando a la vista problemas obvios a resolver y cosas muy buenas que han sucedido, pero no se genera el debido impacto, nada cambia, y se mantiene el status quo de las cosas a lo largo de los sprints.

Un tema que es crítico en cuanto a la organización de los equipos es el micromanagement, del cual ni siquiera voy a decir mucho, porque creo que es parte del sentido común saber que es una práctica abusiva cuando se practica periódicamente. Pero si creo que es interesante que todos(los jefes/líderes sobre todo) estén conscientes del mal/cansancio que genera a nivel mental; además de que en el ámbito del desarrollo solo acaba incrementando el número equivocaciones, ya que la persona presionada a terminar algo lo antes posible tiene muchas más chances de entregar código con errores.

Y ya cerrando quiero agregar, que la organización de la rutina, tanto personal como de un equipo, debe estar fundamentada por preguntas que sirvan realmente para que los demás entiendan lo que se está haciendo, y no solamente justificar diciendo "Así es como funciona Scrum/Agile/Kanban, y así se tiene que hacer". La explicación de los rituales(que no siempre se hace), debe coincidir con la implementación de los mismos.
Las reuniones que están generando más distracción que valor deben ser omitidas siempre que fuese posible. Como ya dije en otros artículos, no existe una receta fórmula perfecta para todos los proyectos/equipos, y eso pasa porque la dinámica va a depender principalmente de:

El contexto en que se desarrolla el proyecto. No podemos comparar un equipo de trabajo de alguna de las empresas MAANG, con el de una startup de latam, o al de una Pyme(pequeñas y medianas empresas).
Las personas que constituyan el equipo. Estamos muy equivocados si no tenemos en cuenta que todas las personas están atravesadas por una subjetividad de la que ni siquiera somos conscientes.