DÍA 3 / 2019

Aporta valor a tu equipo más allá de HTML, CSS y JavaScript

Así que ya te consideras un experto o experta en HTML, CSS y JavaScript. Pero ¿crees que es lo único que puedes hacer por tu equipo? ¿Qué harías si te dijera que dominar los lenguajes del desarrollo web es solo el principio? Acompáñame para descubrir otras maneras de aportar valor más allá de la programación pura y dura.


Cuando alguien que se dedica al desarrollo de Front-end me pregunta cómo puede progresar en su carrera, siempre les respondo con otra pregunta: ¿Cómo crees que estás aportando valor a tu equipo? Normalmente la respuesta tiene mucho que ver con sus habilidades técnicas y su conocimiento de HTML, CSS y JavaScript. Pero en mi opinión, dominar los lenguajes de programación que utilizamos para construir aplicaciones web es solo el punto de partida.

Con este artículo me gustaría explicar mi punto de vista acerca de cómo crecer como profesional, siendo especialista en desarrollo Front-end. Y ya te adelanto que tiene mucho que ver con dejar de mirarte al espejo y comenzar a mirar a tu alrededor.

Observa cómo trabaja tu equipo

Mi primer consejo es que dejes de preguntarte qué puedes hacer para mejorar y empieces a fijarte en qué puedes hacer para ayudar a los que te rodean. Haz una lista de todo aquello que os hace perder tiempo, os bloquea o simplemente no le veas sentido. No importa si aún no tienes una solución o incluso si piensas que ni siquiera tiene arreglo.

Esa lista puede tener todo tipo de cosas, pero ahí van algunos ejemplos que me he encontrado en mi carrera que podrían inspirarte:

  • Perdemos mucho tiempo probando manualmente lo mismo una y otra vez.
  • Cuando empiezo la siguiente tarea, a menudo tengo que parar para arreglar bugs de tareas anteriores.
  • Nos da miedo subir algo a producción, siempre rompemos algo.
  • Hay partes del código que nadie se atreve a tocar.
  • Al entregar una funcionalidad, la diseñadora ve el resultado y no se parece a las especificaciones que nos dio al principio del desarrollo.

Si te identificas con alguna de estas frases, sigue leyendo. Solucionar estas situaciones está en tu mano.

Crea conciencia colectiva sobre los problemas identificados y la necesidad de solucionarlos

Los mejores compañeros con los que he trabajado no tenían todas las respuestas a estos problemas, pero sí tenían la habilidad de identificarlos, adelantarse a ellos y crear conciencia colectiva.

Encuentra un momento para revisar con tu equipo cómo estáis trabajando. Qué está funcionando bien y qué podéis mejorar. Si trabajáis con alguna metodología ágil, puedes hacerlo en una sesión de retrospectiva, pero no hace falta que esperes a ese momento. Lo importante es que confirmes si esos problemas que has identificado son percibidos de igual modo por el resto y si puedes conseguir ayuda para empezar a trabajar en mitigarlos.

Intentad enfocaros en dos o tres cosas como mucho y probar acciones que os acerquen al estado en el que queréis estar. Revisad si estas acciones están funcionando y si no lo hacen, por qué no.

Seguramente no estoy descubriéndote nada nuevo: es uno de los principios fundamentales de la agilidad: inspect and adapt.

Foto de Kyle Glenn en Unsplash

Rompe los silos

El desarrollo de software es una actividad colectiva. Por eso todas las empresas modernas acaban entendiendo que la mejor organización consiste en diseñar equipos de personas con diferentes especialidades y ponerles a trabajar en el mismo problema. Pero esta colaboración no funciona de forma óptima si se convierte en una cascada en la que os vais traspasando el trabajo por hacer. Eso es una factoría de software y no suele acabar bien.

¿Te has encontrado alguna vez implementando un diseño que han trabajado de antemano tus compañeras del equipo de diseño y hay patrones que no encajan o no tienen sentido? ¿Has tenido que detener un desarrollo para pararte a arreglar defectos encontrados en algo que ya estaba entregado por no haber considerado casos límite al testear?

Romper los silos significa evitar hacer un traspaso de conocimiento entre diseño, desarrollo, QA y puesta en producción. Trabaja en romper esas barreras para que todos habléis el mismo idioma.

Puedes proponer tener una guía de estilos, un sistema de diseño o una librería de componentes visuales para que la comunicación entre diseñadores y programadores sea más fluida. Y lo más importante: que nadie tenga que rehacer su trabajo.

En cuanto al testing, convence a los especialistas de QA en que se involucren contigo desde el principio. Hazles partícipes de las pruebas unitarias que introduces mientras programas y así evitar que inviertan tiempo en tests end to end más costosos y frágiles. Deja que te sugieran probar casos límite, porque solo ellos tienen esa sensibilidad para encontrarlos.

Imagen de bluecoders

Involúcrate en el diseño de APIs de Back-end

Siguiendo en la línea de romper silos, me gustaría dedicar un capítulo aparte a la interacción entre el Front-end y el Back-end. Si trabajas en proyectos que exponen APIs desde vuestros servicios en el Back-end, piensa que esos servicios están pensados para que se consuman desde aplicaciones de cliente que vas a desarrollar tú. Puedes verlo como una relación en la que tú eres el consumidor de un servicio que te proporcionan otros. Y como consumidor, tu participación en el diseño de estas APIs es muy importante.

Si el resto de tu equipo planifica diseñar el contrato de un endpoint, no pienses que “eso es responsabilidad de los que se ocupan del Back-end”. Aprende cómo diseñar una buena API y piensa en cómo la vas a consumir. Si es un endpoint para un listado, asegúrate de que vas a poder obtener toda la información que necesitas mostrar en una llamada, y evitar el típico problema de hacer n+1 peticiones al Back-end. Lee y domina conceptos como eventual consistency y optimistic ui para evitar realizar llamadas síncronas que bloqueen la experiencia de usuario y se conviertan en un detrimento del rendimiento percibido.

Plantéate qué patrones de diseño están utilizando otras empresas para resolver problemas que ya tienes. ¿Os conviene usar Graph QL u otra solución para hacer Backends for Front Ends BFF? ¿Es algo que tiene sentido en vuestro escenario o bastaría con adaptar el contrato de la API?

No lo dudes: tu participación como consumidor de los servicios que diseña tu equipo es fundamental. ¡Involúcrate!

Ofrece soluciones para habilitar la experimentación

Seguro que has oído alguna vez la expresión Test early, test often; fail fast, fail cheap o alguna de sus variaciones. Es un concepto íntimamente relacionado con Lean Software Development. Una mentalidad que incorpora el aprendizaje como una parte esencial del proceso de desarrollo de software.

Tomar decisiones de producto basadas en datos es importante, pero no es suficiente. Los datos pueden mostrar que un porcentaje relevante de usuarios añaden productos al carrito de la compra y nunca compran nada, pero no te dirán por qué.

En equipos que realizan desarrollo de software Lean, para adquirir ese conocimiento se empieza un ciclo de formulación de hipótesis y realización de experimentos que te ayuden a validar estas hipótesis, o a aprender y obtener más información para acercarte poco a poco a la solución definitiva.

Para poder fallar rápido, necesitas habilitar a tu equipo de herramientas que os permitan hacer pruebas baratas de forma segura. Baratas en términos de esfuerzo dedicado para ponerlas en marcha y seguras de modo que causen un impacto mínimo o nulo en caso de que no sean satisfactorias.

Como especialista en Front-end, hay muchas soluciones que puedes aportar para que tu equipo pueda experimentar sin tener que invertir demasiado esfuerzo. No dudes en tirar de creatividad: se trata de probar soluciones con la idea de descartarlas, incluso si los resultados son buenos.

Por ejemplo, piensa en cómo puedes diseñar tu plataforma para habilitar el uso de Feature Toggles para un volumen controlado de usuarios. O cómo liberar en producción varias versiones de la misma funcionalidad y hacer un experimento para comprobar cuál da mejor resultado, descartando el resto.

Automatiza todo lo que es repetitivo y propenso a errores humanos

Las personas estamos preparadas para ser creativas y se nos dan muy mal las tareas repetitivas, aunque el sistema educativo desde la revolución industrial ha intentado convencernos de lo contrario. Pero se nos dan mal, somos lentos haciéndolas, son aburridas y nos hacen cometer errores.

Pero afortunadamente, tenemos máquinas a las que se les dan muy bien. Tan solo hay que encontrar las herramientas adecuadas y echarle un poco de creatividad para hacer scripts que las hagan por nosotros.

Cuando te pedía al principio del artículo que observases a tu alrededor, seguro que muchas de las cosas que acabas detectando se deben a errores humanos. Problemas en la integración con el código hecho por otros, o con servicios desarrollados por terceros, bugs, regresiones, elementos descolocados en la interfaz de usuario… Absolutamente todo se puede automatizar.

Por ejemplo, si consumes una API desarrollada por otro equipo y quieres asegurarte de que no te rompen nada cuando hacen cambios, puedes implementar una batería de tests utilizando alguna herramienta de Consumer-driven contract testing como Pact o simplemente escribiéndolos en tu framework favorito. Pídeles que la ejecuten como parte de su proceso de release y así serán conscientes de que han provocado una regresión en uno de sus consumidores.

Si quieres asegurarte de que tus webs son accesibles pero no sabes cómo verificarlo de forma recurrente, puedes considerar utilizar herramientas como pa11y para tener feedback cada vez que introduces algún cambio.

Si trabajas en una empresa donde son muy quisquillosos con el diseño y te piden que tus implementaciones sean pixel perfect, puedes hacer dos cosas: la primera, decirles que el pixel perfect no existe: son los padres. Y la segunda, si lo primero no funciona, utilizar una herramienta de testing visual automático, que compara capturas de pantalla entre diferentes versiones y te avisa cuando algo se ha descolocado. En una empresa que estuve trabajando utilizábamos aplitools, pero no es la única.

Podría escribir un artículo entero solo hablando de herramientas de automatización, pero mi punto es que para cada problema tedioso, existe una solución que lo hace por ti de forma automática, más rápido y más fiable.

Imagen de Stephen Dawson en Unsplash

Visualiza y anticípate a los problemas

He insistido varias veces a lo largo del artículo en la importancia de tu trabajo de cara a la percepción que tienen los usuarios de vuestro producto. Tu misión no consiste solamente en entregar una interfaz gráfica funcional acorde con las especificaciones. Tampoco finaliza una vez entregado, sino que solo es el principio.

Si tu equipo de producto decide desarrollar algo, es con la intención de conseguir un efecto. Más conversiones, menos abandonos, mejorar la interacción... Pero ¿estáis midiendo si conseguís el resultado esperado antes de poneros a hacer otra cosa? ¿Sabes qué tipos de usuarios tienes, qué dispositivos usan, cómo navegan por tu aplicación?

Saber cómo se comportan tus usuarios puede ser clave para decidir una estrategia óptima de code splitting. Si no lo tienes aún, pide acceso a los datos de la herramienta de analítica web que utilizáis y analízalo con tu equipo.

Conocer qué errores se producen en el browser de tus clientes puede evitar que tu empresa pierda dinero. Hay errores que no se detectan en los logs de servidor, porque son propios de JavaScript y evitan que se pueda buscar, contactar, comprar... o cualquiera que sea tu métrica de éxito. Para estar al tanto de este tipo de errores, hay herramientas como Rollbar, Airbrake o Sentry, por citar algunos ejemplos.

Por último, no olvides visualizar y trabajar activamente en mantener el rendimiento de tu web a ralla. Como decía mi camarada Miguel Ángel Durán en una de sus newsletters, "medir el rendimiento es clave para SEO, conversión y para ofrecer una imagen impecable de tu marca". Utilizar Lighthouse es un buen comienzo, pero no es demasiado complicado implementar un pequeño cliente que alimente tu herramienta de logs y construir un panel de control para visualizar los números producidos por tus usuarios. Para ello, te aconsejo que investigues la API de performance. Google tiene un montón de recursos para aprender y comenzar a medir, aquí tienes un buen punto de partida.

Imagen de Lynne Cazaly

Aprende de los últimos 20 años de historia del desarrollo de software

En el 2001 se juntaron en una cabaña diecisiete señores a discutir sobre modelos de mejora del desarrollo de software basados en procesos. De aquella barbacoa de Boy Scouts salió lo que hoy conocemos como el Manifiesto por el desarrollo Ágil de Software. Pero durante los 90, Kent Beck ya hablaba de los beneficios de trabajar con prácticas de Extreme Programming, sin las cuales el desarrollo Ágil no sería posible.

Hoy en día las aplicaciones Front-end han alcanzado una complejidad (necesaria, por otro lado) que hace diez años era impensable. Eso hace que nos tengamos que tomar más en serio cómo entregamos código de calidad, de forma sostenible y compartimos conocimiento. Técnicas como Test-Driven Development, Pair Programming y otros valores de XP te pueden ayudar a crear dinámicas de equipo que os hagan rendir de forma óptima.

Sí, soy consciente de que te habrán hablado mucho de Agile y que según quién lo haya hecho, hasta puede provocarte un comprensible rechazo. Se ha pervertido mucho el concepto a lo largo de los años.

Pero no deja de ser historia de la industria en la que trabajas y siempre viene bien aprender de ella para no cometer los mismos errores. Aquella gente ya se enfrentaba a los problemas que tú probablemente estés sufriendo y propusieron técnicas que mitigan sus efectos. No lo subestimes, abrázalo y esfuérzate por entenderlo.

Conclusiones

Los que nos dedicamos a programar aplicaciones web estamos en una posición de privilegio, ya que tenemos la oportunidad de interactuar con todas las ramas de especialistas que intervienen en el ciclo de desarrollo. Tus usuarios percibirán qué es tu producto a través de la interfaz que tú has desarrollado. Percibirán la calidad de vuestra marca a través de los pequeños detalles. Sufrirán los errores y problemas de rendimiento y se deleitarán cuando la UX y el diseño se sientan tal y como se diseñaron en los primeros prototipos. Tu objetivo puede ser convertirte en la persona que haga que todas esas piezas encajen y tengan sentido.

He querido reflejar en este artículo el enorme abanico de opciones que tienes ante ti para aportar valor a tu equipo más allá del dominio que puedas tener de los lenguajes que utilizamos cada día.

La mayoría de estos consejos no tienen nada que ver con el desarrollo de Front-end en sí mismo, pero si quieres crecer como profesional, no puedes verte solo como alguien especialista en picar código. La ingeniería de software es una profesión desafiante porque te enfrentas a nuevos problemas a resolver cada día. Muchos de estos problemas no tienen nada que ver con el código, sino con cómo trabajan e interactúan las personas que forman parte de un equipo para construir un producto de éxito.

Dani de la Cruz

He trabajado como ingeniero de software durante más de una década, mi segunda lengua es JavaScript y ahora me considero desarrollador de productos y solucionador de problemas. En mis ratos libres hago de mentor para programadores y programadoras que quieran dar un salto en su carrera profesional.