Bienvenido a un nuevo vídeo de MiduDev. Hoy vamos a hablar sobre la leyenda de los fullstack.
Vamos a ver si es postureo, si realmente existen, si tienen utilidad, qué significa realmente ser fullstack.
Y para eso, pues hoy traigo un invitado. Tenemos hoy aquí a Daniel de la Cruz. Bienvenido, Dani. ¿Cómo estás?
Hola, estoy muy bien. Hacía mucho tiempo que no nos veíamos.
Sí, bueno, de vernos en persona todavía más tiempo, pero sí en actual.
Vale. Oye, encantado de que estés aquí. Te traigo porque sobre todo el otro día hablaste en Twitter del tema de los fullstack.
Es un tema que hace mucho tiempo que quería hablar y lo petaste, ¿no? Con el tweet este. ¿Qué pasó?
Sí, pues no sé. El hecho es que yo llevaba bastante tiempo queriendo escribir un artículo en mi blog, pero me daba un poco de pereza.
Lo intenté dos veces. Me estaba saliendo muy largo y antes de descartarlo, pues dije, bueno, voy a intentar poner en un hilo las cuatro ideas que tengo y ya está.
Bueno, estoy contento porque a la gente le ha interesado el tema, le ha gustado. Además, creo que tenía un plot twist interesante el hilo.
La gente se pensaba que iba a hablar de una cosa y acababa hablando de otra, pero bien, ahí está. Interesante.
Es que de los fullstack el tema este siempre interesa un montón, ¿no? Porque yo creo que sobre todo en el tema de desarrollo web, y esto es una cosa que me gustaría que hablásemos, ¿vale?
Del tema de por qué se suele hablar mucho de fullstack, sobre todo para los programadores web y no tanto a veces para backends y tal.
Pero bueno, eso más adelante. Spoiler de lo que vendrá más adelante, ¿vale?
Eso es curioso, sí.
Es súper curioso. Es un tema súper candente. O sea, siempre la gente, pues hay gente que no cree que existan los fullstack.
Hay gente que cree más en la hiperespecialización. Hay gente que sí, que considera que es necesario.
Entonces, ¿cómo lo ves tú? Así un poco, primeras pinceladas, que el tema de los fullstack. ¿Son unicornios o no? ¿Qué pasa con esto?
Bueno, yo empiezo el libro un poco hablando del contexto casi histórico, ¿no? Porque uno ya lleva unos cuantos años trabajando de esto.
Y yo recuerdo que al principio de mi carrera no había especialistas. No había frontends, backends, no se hacía una diferencia entre diferentes perfiles de programación.
Simplemente tú entrabas en una empresa, ya fuera grande una consultora o un cliente final pequeño, da igual, y había que hacer de todo.
Se hacía y lo que no se sabía se aprendía y punto, ¿no?
Lo que pasa es que esto ha ido evolucionando con los años y ahora tenemos perfiles especializados para todo.
Tenemos el perfil de frontend, el de QA, el de DevOps, el de Site Reliability.
Con cada tendencia nueva y cada sabor nuevo que aparece, pues parece que tengamos que crear una carrera construyendo ese camino.
Tiene sentido porque a lo mejor antes era más sencillo, digamos, estas disciplinas y poco a poco se han ido complicando.
¿Sabes? Que nos hemos visto abocados un poco a tener que especializarnos, por ejemplo, en el frontend hace 15 años.
No sería el frontend de hoy en día, ¿no? Y al final tienes que abarcar tanto, ¿no?
Que te tienes que especializar porque si no, al final no eres suficientemente bueno en ese campo, quizás.
Claro, eso es verdad. Los frameworks que había anteriormente para hacer aplicaciones web, por ejemplo, por centrarnos en un aspecto de ingeniería de software,
pues antes era un todo en uno. Antes era desde la plantilla hasta la base de datos, era casi todo el mismo framework.
Era casi imposible aprender solo una parte del framework, tenías que dominarlo todo.
Pero con el paso de los años han ido saliendo tecnologías nuevas y la complejidad se ha ido desplazando, ¿no?
Es que yo no creo que ahora sea más complejo que antes, sino que ahora hay más cosas que hacer en todas las capas.
Ahora tenemos, por ejemplo, el concepto de observabilidad, que era algo que antes había, pero ahora pues es mucho más completo.
O infraestructura como código en el frontend, pues diferentes capas que acaba siendo casi un stack completo en una aplicación de cliente.
Yo creo que la complejidad se ha desplazado. Creo que hay que hacer lo mismo, más completo, pero sí que esto ha favorecido que haya especialistas,
que haya tantas cosas que aprender en cada layer que nos hayamos especializado tanto.
Me gusta ese concepto de que se ha desplazado la complejidad, porque sí que creo que ha habido mucho desplazamiento hacia el frontend, ¿no?
Quizá antes era más, desde el backend se hace todo y escupe el HTML y en el frontend intenta hacer lo mínimo posible.
Y ahora parece que incluso ha sido, esa complejidad se ha ido directamente al frontend, donde el frontend se está haciendo muchas cosas
y lo que se lleva es incluso a reaprovechar lo que haces en el frontend en el backend, ¿no?
Como el server-side rendering y todas estas cosas.
En realidad es intentar llevar lo que haces en el frontend al servidor.
Por lo tanto, esa complejidad que ahora la tienes en el frontend, digamos que te la saltas esa parte al menos, ¿no?
De las plantillas que antes hacíamos, ¿no? Renderizar el HTML en el servidor.
En realidad es lo que ya tienes en el cliente. Así que me gusta mucho ese concepto.
Y luego aparecen, bueno, aparecen problemas que antes no tenías en una capa como el frontend.
Tienes que aplicar patrones de diseño para resolver problemas de rendimiento.
A lo mejor te encuentras algoritmos o cómo tratar datos, tener que aplicar estructuras de datos.
Una serie de fundamentos de ingeniería que antes la gente que a lo mejor solo hacía maquetación y CSS, pues no tenía por qué conocer, ¿no?
Hay una serie de disciplinas y conocimientos que tienen que ir aprendiendo.
O, por ejemplo, el testing. Claro, hacer test unitarios, test end-to-end en el frontend solo como una aplicación que puede vivir por sí misma encima de una API,
pues antes no tenía sentido y ahora sí, ¿no?
Entonces, bueno, estamos ya llegando a un full start completo en el frontend.
Seguramente, claro, ese es el tema, ¿no? Que hemos ido mejorando la experiencia del usuario en el frontend, ¿no?
Con experiencias más ricas, más completas.
Y esto lo que está haciendo es que todo lo que pasa en el frontend se vaya haciendo más complicado.
Por ejemplo, single page application, ¿no?
Tenemos una experiencia mucho más rica donde la navegación ocurre sin ir al servidor.
Y esto hace que la parte del cliente sea más complicada.
El testing en el cliente sea más complicado.
Porque si antiguamente decíamos, bueno, vamos a ver si en el HTML están estos tres elementos.
Ya, ¿no? Pero es que ahora tienes que testear la navegación o si le das a este botón, si se despliega esto, ¿no?
Y entonces eso a lo mejor antes era mucho más sencillo.
Todo se complica y es lo que dices tú, que además el conocimiento que necesitas también va haciéndose más amplio.
Claro, claro. O reglas de negocio, ¿no?
Reglas de negocio optimistas que se aplican en el frontend antes de ir al backend.
El enrutado, antes todas las rutas se resolvían en el backend.
Ahora se puede hacer una navegación completa en el frontend.
Son casi aplicaciones nativas.
¿Crees que tiene que ver el tema de los frameworks y librerías?
O esto es algo que siempre ha pasado, ¿sabes?
Ha sido la irrupción también de esta especialización que tenemos que tener.
Porque, claro, han salido pues React, Angular, Vue, Svelte y todas estas.
Y te obligan de alguna forma a tener que hacer esto.
Yo creo que es... No creo que sea la causa, pero sí que tiene mucho que ver.
Es decir, antes cuando hacías jQuery, pues no tenías tanto problema para hacer una aplicación en el frontend.
Y de repente se pedía que la gente no solo conociera jQuery como librería, como utilidad,
sino que tuvieran fundamentos sólidos de programación y de un lenguaje que alcanzó también su madurez como JavaScript.
En 2015, con todo lo que trajo consigo el estándar del lenguaje, pues alcanzó una madurez como lenguaje de programación
que creo que antes no tenía del todo.
Todo esto y el hecho de poder hacer pues llamadas a APIs o soluciones tecnológicas como Firebase,
comunicar directamente con un repositorio de datos.
Todo este abanico de posibilidades que te permite ahora el frontend, antes no existía y no era una necesidad.
Entonces ocurrió una cosa, que el mercado de ingenieros, ingenieras de software no tenía especialistas en JavaScript.
A lo mejor tenía gente muy buena en frameworks de backend, como PHP, como .NET, Java, incluso Node.
Pero había poca gente haciendo frontend en el frontend que supiera muy bien programar y muy bien JavaScript.
Claro, ¿y qué pasa con esa gente de repente? Eso me lo he encontrado yo en muchas empresas.
Gente que durante muchos años han estado ahí haciendo ese .NET que desde el backend, digamos,
que ya te permite hacer la capa mínima de presentacional, incluso poner algo de JavaScript y tal,
pero una forma muy básica, muy simple.
Pero claro, de repente, pues cambia todo esto, ¿no?
Lo que dices, se desplaza la complejidad en el frontend, se empieza a hacer más cosas, más, mejores prácticas,
experiencias más ricas para el usuario.
¿Y qué pasa con esta gente, no?
Porque a mí me dio la sensación un poco en muchas empresas que no se llegó a formar adecuadamente a mucha gente, ¿no?
Y hubo una ruptura, digamos, que esa gente quedó como que además como que no quería ese cambio, ¿no?
Como de, no, no, no, yo no quiero esto, no quiero saber nada de esto.
Entonces, ¿cómo lo ves tú esto?
Fíjate lo que me pasó a mí y lo que pasó en mi empresa a mucha gente.
Yo llevaba una trayectoria de especialización en un lenguaje como .NET que de repente tenía que elegir o hiperespecializarme en .NET,
pero solo backend, solo de la API hacia atrás.
Sin muchas cosas que me gustaban, como pues toda la parte de modelo vista controlador, de creación de plantillas, HTML, CSS,
tenía que elegir entre hiperespecializarme en backend o perder toda esa trayectoria de experiencia en .NET
y empezar de cero en algo como JavaScript.
Y tuve que elegir porque no solo nuestra empresa, sino el mercado empezaba a demandar eso.
Entonces había dos caminos posibles para la gente que ya estaba trabajando.
O te quedabas en el backend y renunciabas a hacer una serie de cosas y era lo que te gustaba.
O empezabas a formarte y aprender casi una disciplina nueva.
Pero poca gente hizo este camino.
Yo lo hice, pero muy poca gente hizo este camino.
¿Sabes una cosa que me parece muy interesante de esto que estamos comentando?
Es que esto a día de hoy le pasa a mucha gente.
A mí me escribe muchísima gente que me dice,
oye, soy backend y ahora, claro, quiero cambiar totalmente.
Me gusta más el frontend, pero tengo un problema.
Yo gano X y ahora me están pidiendo ser especialista de frontend,
pero claro, yo no tengo tres, cuatro años de experiencia haciendo JavaScript.
Entonces, ¿cómo doy este salto?
Porque yo no quiero bajar mi sueldo porque tengo experiencias de desarrollo.
Pues tengo diez años de experiencia, pero claro, no sé tanto de JavaScript.
Y claro, la verdad es que esto que comentas,
que parece que es algo que nos enfrentamos muchos hace a lo mejor diez años, ocho años.
Pero hoy en día sigue vigente, ¿no?
De que mucha gente se está dando cuenta de que para dar este salto, ¿cómo lo hace?
Mi consejo, y a ver si coincides tú, a ver,
y creo que también para ayudar a la gente,
que seguro que es gente que nos estará viendo y escuchando.
Yo lo que les digo es animarles a hacer este approach más full stack dentro de un equipo
en su perfil ya de backend,
que realmente vaya haciendo per programming con tareas de frontend dentro del equipo.
Incluso creo que es algo positivo y esto creo que lo hablaremos después,
para hablar sobre el tema de lo full stack.
Pero es positivo no solo para él, sino para el equipo,
para el hecho de tener más posibilidades dentro del equipo,
de que alguien pueda tomar esas tareas de frontend.
Entonces, en lugar de hacer un cambio brusco en tu carrera,
de decir, no, me cambio de empresa, empiezo de cero,
desde la empresa en la que estás seguramente intentar buscar ese cambio ya
para que poco a poco vayas tomando esta experiencia.
Es muy interesante esto que comentas porque a mí me pasa justo también al contrario.
A mí me escribe mucha gente que me conoce de mi actividad en redes hablando de frontend
y preguntándome qué tienen que hacer para seguir progresando en su carrera.
Y yo normalmente lo primero que les digo es, bueno,
¿sabrías montar un servicio o diseñar una API o desplegar código en producción?
Y me dicen que no.
Entonces, claro, hay todo un recorrido ahí que se puede hacer
para contribuir en tu equipo más allá de tu especialización.
Llámale a eso ser full stack o no, me da igual,
pero de lo que se trata aquí es que la gente que gestiona equipos,
que gestiona personas que trabajan en un equipo,
incluso las empresas, deberían favorecer que se produzca esta colaboración
y compartir conocimiento entre los miembros de un equipo.
Así todo el mundo crecerá y crecerán en un modelo T-shape que se llama.
Es decir, tú tienes una especialidad en la que eres fuerte, en la que tienes confianza.
Que es el tronco.
Y en la que has el tronco, en el que has construido la mayor parte de tu carrera,
pero luego vas abarcando ramas, por así decirlo,
de otras modalidades, otras especialidades en las que a lo mejor no vas a ser tan bueno
porque no vas a ser tan especialista en eso,
pero vas a poder ayudar a tu equipo.
Y un ejemplo muy bueno es alguien que a lo mejor lleva X años de experiencia en backend
y sabe muchas cosas de cómo hacer una pipeline de continuous integration,
cosas de infraestructura, cómo diseñar una buena API, cómo testear.
Todo ese conocimiento, si esa persona hace pay programming con gente de frontend,
puede mentorizarles y ayudarles a crecer y aplicar ese conocimiento en el frontend,
que también es válido, tanto patrones de diseño como buenas prácticas, lo que haga falta.
Por un lado, parece que la industria o cierta parte de la industria ha ido hacia un lado,
que es, por ejemplo, el tener especialistas de QA, que lo has comentado antes,
o tener especialistas de DevOps, que hacen solo infraestructura,
especialistas de backend, los mejores frontend.
Entonces, como que separados, eso por un lado.
Y por otro lado, pues tenemos esa figura de unicornio, que muchas veces habla de full stack,
que hay gente que se cabrea y todo.
No, full stack no existen y tal.
Pero que va un poco alineado con esto y yo creo que es la mentalidad ya hay.
El hecho de tener equipos autónomos, de que puedan hacer las tareas lo más rápido posible,
sin necesidad de depender de otro.
Porque al final, si tú dependes de lo que hace el QA, el otro depende de lo que hace el backend y tal.
Al final es un mini waterfall de libro, en el que cada tarea pasa de uno al otro.
Y al final lo que tú quieres es que los equipos sean totalmente autónomos.
Y entonces, como que yo veo que estas dos cosas como que colisionan.
¿Sabes? Como que, ¿por qué por un lado tenemos estos especialistas que al final se siguen buscando,
pero por otro lado tenemos estas mentalidades agile que se supone que tienen las empresas,
en las que están buscando justamente esto, ¿no?
Y parece que colisionan y les cuesta, ¿no? Como convivir estos dos mundos.
Ocurren varias cosas aquí con todo esto.
La primera es que es verdad lo que comentas, que se produce un intercambio de tareas a la hora de desarrollar un proyecto.
Imagínate que empieza una...
Un equipo tiene que resolver un problema de los usuarios y empieza el desarrollo.
Y normalmente yo lo que he observado en empresas es que llega la persona de producto, llega la persona de diseño,
plantean el problema y parte de él cómo resolverlo también.
Y entonces empieza a encargarse los dos o tres especialistas de backend, hacen el servicio.
Hasta que no lo terminan, la gente de frontend no puede programar porque dicen,
ah, no tengo ningún servicio, no puedo hacer mi frontend, no puedo hacer nada.
Entonces luego se hace un handoff a gente de frontend.
Cuando la gente de frontend lo termina, lo coge la gente de QA,
escribe test de automatización, lo prueba.
Y si todo va bien, eso a lo mejor acaba hasta en un equipo de despliegue a producción,
release management, DevOps, llámale como quieras.
Y es esa gente que no ha desarrollado eso la que lo acaba poniendo en producción.
A veces incluso se produce el antipatrón de tener equipo backend,
equipo frontend y equipo QA que ni siquiera trabajan juntos.
Sí, sí, que son totalmente separados, que ya sí que es una locura.
Y aunque trabajen en el mismo equipo, a lo mejor no hablan.
A lo mejor hay tareas que son solo de backend y solo de frontend
y nadie tiene el conocimiento, Antuen, de cómo se tiene que implementar eso.
Yo creo que esto no deja de ser un waterfall.
Estamos enmascarando lo que hemos hecho siempre en una capa de framework agile,
pero en realidad no estamos haciendo agile.
Nadie está trabajando en resolver problemas de los usuarios,
ni se produce colaboración, ni se comparte conocimiento.
Estamos optimizando la hiperespecialización, por así decirlo.
Claro, exacto.
Y yo creo que las empresas fallan y fallamos,
y yo me incluyo, cuando confeccionamos equipos.
Cuando decimos, vale, primero, ¿cómo es mi producto?
¿Cómo se divide mi producto?
¿Qué contextos tiene?
¿Qué dominios tiene?
Luego, ¿cómo voy a hacer escalar mi empresa?
¿Qué equipo se va a encargar de esto?
¿Y cómo voy a compartimentar mi producto para que este equipo sea autónomo,
en el sentido de que pueda decidir cómo y cuándo poner cosas en producción
sin depender de otros?
Y una vez has hecho esto,
entonces piensas en los perfiles que necesitas en ese equipo,
igual que en un equipo de un deporte, en un equipo de fútbol.
Necesitas, no es lo mismo jugar con un 4-4-2 que con un 3-4-3.
Necesitas delanteros, defensas, front-ends, back-ends, especialistas.
Y luego, defines el rol de las personas que estás buscando.
¿Qué es lo que pasa normalmente?
Pues que las empresas buscan full stack React,
o QA con automation y JavaScript.
Y no buscan personas que resolvan problemas,
que tengan habilidades como desarrollo de aplicaciones tal,
o resolución de este problema.
Ahí es donde creo que estamos fallando.
Que una especialidad tan antigua como la búsqueda de perfiles de recursos humanos,
pues todavía no abraza la mentalidad Gile que tiene que alcanzar la empresa.
Porque es que Gile no es solo para los equipos de desarrollo,
es para toda la organización.
Es que si no, no funciona.
O sea, no puedes tener el equipo de desarrollo que sea Gile
y todo lo demás haciendo el waterfall o lo que sea.
No tiene sentido.
Hay una cosa muy interesante sobre lo que comentas,
y yo creo que a lo mejor ahora hay gente que está escuchando esto
y ya está un poco así con las uñas para adelante.
¡Ey! ¿Qué me estás diciendo?
Que yo soy front-internet.
¿Qué dice este tío?
Que tengo que aprender backend.
¿Qué es esto?
¿Sabes?
O soy QA y tengo que aprender a desarrollar.
O yo qué sé.
Hay una cosa que has comentado que a mí me parece súper interesante
y que creo que tiene que ser, que tiene que quedar cristalino.
Creo que como individuo es importante que seamos lo más T-shape posible,
¿vale?
Pero no se busca o no se debería buscar, que es lo que dices tú,
a un hombre orquestra, ¿no?
Que es el...
O un hombre o mujer orquestra.
La persona que lo hace todo.
Que no tiene sentido.
Lo que sí tienen que ser autónomos son los equipos.
Ahí.
No las personas.
O sea, cuanta más autonomía tiene una persona de forma individual,
mejor, obviamente.
Pero no se busca que una persona lo pueda hacer todo.
Porque es el equipo que confeccionas.
Como bien has dicho, ¿no?
Tú lo que tienes que hacer es una configuración de equipo.
Que hay veces que tienes un equipo de solo tres personas,
que a lo mejor funciona súper bien.
A lo mejor hay otra.
Necesitas seis personas.
Y tienes que poner a una persona de marketing.
Porque las cosas que van a hacer, ¿no?
Pues tienen con marketing.
Y tiene la persona de marketing que saberá desarrollar.
Pues a lo mejor no es malo, ¿sabes?
A lo mejor no está mal que empiece a hacer tareas sobre desarrollo.
¿Por qué no?
Claro.
Porque eso le va a dar un contexto dentro del equipo
que le va a ayudar a hacer esas tareas.
¿Que se le está pidiendo que sea experto en React?
No, no se le está pidiendo eso.
Dentro de su experiencia y de su desarrollo personal
que habrá hecho de ser de marketing,
cuanto más vaya ampliando un poco su autonomía,
sin ser al 100%,
más en el equipo podrá ayudar y hará que las tareas fluyan, ¿no?
Y qué es lo que se busca.
Pero insisto, y esto es súper importante,
son los equipos los que tienen que ser autónomos
con una configuración de personas idónea.
No una persona tiene que saber de todo.
Que cuanto más sepas, obviamente, ¿sabes?
Lo que se busca es que te expandas dentro del contexto dentro de tu equipo
para que puedas ayudar al equipo a entregar esas tareas.
Eso sí.
Es que a veces esto como que no encaja bien, ¿no?
Y es lo que has dicho, y me parece súper interesante,
las ofertas de trabajo que busca React, Fullstack,
Travis DevOps, Infrastructure, no sé qué, no sé cuánto.
Y entonces, que puede ser que exista, pero no es tanto eso.
Lo que se busca es que sean personas que sí que pueden ser,
que sepan React y tal, pero que tengan experiencia en otros temas
y que a lo mejor dentro del equipo donde vayan a estar
puedan ampliar, a lo mejor en una entrevista más interesante,
saber si a esa persona le interesa dentro del equipo donde va a estar,
ampliar sus conocimientos hacia marketing, ¿sabes?
Porque no, es que vas a un equipo de marketing,
que tienes que saber un poco de esto,
o que tú vas a maquetar los mails,
nos gustaría que supieses de esto.
¿Es algo que te interesa?
Si te dice que no, seguramente, por muy experto que sea,
ya no te interesa tanto.
No es tanto la experiencia que tengas,
sino que busca ampliar.
Y creo que eso es algo bastante interesante.
Es que lo has clavado.
Yo creo que es exactamente eso.
Es la configuración del equipo a la que tiene que estar balanceada
y la autonomía se consigue cuando el equipo es capaz
de resolver los problemas que tiene que resolver por sí mismo.
Y hay equipos que a lo mejor necesitan a alguien de marketing
y equipos que necesitan, pues, siete especialistas de backend.
Porque los problemas que tienen que resolver,
tienen que resolverse en ese contexto.
O gente de datos, gente que sepa capaz de explotar
y analizar los datos y medirlos.
A lo mejor hay un equipo que necesita más de eso.
Otra cosa que me gustaría señalar es que con la gente que desarrollamos,
la gente que estamos programando,
no solo deberíamos interesarnos por el backend, el frontend
o la especialidad que nos falta, sino también por el producto.
¿Cómo funciona nuestro producto?
¿Cómo lo utilizan nuestros usuarios?
¿Cómo resolvemos ese problema?
Desde nuestra habilidad de ingeniero, de software.
Que al final la ingeniería no es más que eso.
Abrazar el problema y ofrecer una solución creativa.
Entonces, mientras más cerrado sea tu alcance,
más información te va a faltar para ofrecer una mejor solución.
Hay veces que como desarrolladores a lo mejor decimos,
no, yo ya he desarrollado esto, aquí lo dejo.
Siguiente paso.
¿Sabes?
Como si fuese un paquete y dices, bueno, que lo entregue,
pues haga el CUA y el CUA ya le dirá a la gente que haga deploy
y ya el usuario verá y el product owner me dirá si todo está bien.
Además que ese proceso de desarrollo es súper ineficiente,
porque fíjate que antes he dicho,
si todo va bien, se acaba entregando y se acaba poniendo producción.
Si todo va bien.
Además de que cuando algo se pone en producción,
no termina el desarrollo,
porque eso hay que medirlo y ver si realmente está resolviendo el problema
y consiguiendo los resultados que querías.
Todo esto es si va bien,
pero si va mal normalmente lo que pasa,
y cualquiera que nos esté escuchando
y lleve unos cuantos años de experiencia,
sabe que lo que realmente pasa
es que alguien termina su trabajo,
lo coge la otra persona
y hay que rehacer cosas,
porque hay malentendidos,
porque ha habido un problema de comunicación,
porque como somos Ayael,
no planificamos desde el principio cómo se va a hacer todo,
sino que estamos trabajando en pequeños hilos
y cuando lo coge el frontend,
ostras, me faltan estas propiedades en la API,
vale, vamos a tirar el trabajo para atrás.
Lo acaba frontend y lo cogen los testes,
ostras, esto no funciona como se espera,
o he encontrado tales las,
o he escrito este test y se rompe,
o otra vez tirando para atrás.
O lo ve la persona de diseño al final de todo el proceso,
ostras, esto no era lo que yo había pensado,
o yo no lo había diseñado para responsive.
Si no hay colaboración desde el principio,
se produce retrabajar las cosas
y eso es un desperdicio
y el proceso que va a tener eficiente.
Y aquí justamente yo creo que es donde entra,
más que nunca,
la aspiración de full stack.
Y yo creo que cuando hablamos justamente de full stack,
y esto lo habremos encontrado todo el mundo,
que cuando estamos en una empresa,
por ejemplo,
y tenemos un UX,
que resulta que también sabe maquetar,
que también sabe hacer frontend.
Y cuando hablas con esa persona,
como que la conversación fluye mejor.
Y justamente esto,
esta aspiración de ser full stack
y en la que se tiene que trabajar,
es si eres frontend,
te tiene que interesar el backend,
porque es parte del producto,
porque además sabiendo hacer cosas de backend,
esto no solo tú algún día podrías hacer esa tarea,
sino que la comunicación va a ser mucho mejor.
Si haces pay programming con esa persona,
inmediatamente vas a decir,
ostras, no,
pero en el backend vas a necesitar hacer esto o lo otro,
o al revés.
Los cuáles.
Es que no tiene sentido una persona
que solo sepa testear,
porque, a ver,
tiene sentido,
porque hay muchos especialistas sobre esto,
pero en realidad donde va a dar lo máximo
es saber testear sobre desarrollos
que puede hacer esa persona.
Porque va a encontrar patrones
que,
por qué esto lo ha hecho así,
entender,
empatizar.
Qué importante empatizar.
La palabra empatía.
La empatía es el dios del agile,
yo creo,
y es lo más importante.
Y es que empatizar,
saber lo que siente el otro,
cómo lo desarrollaría,
qué problemas se ha podido encontrar,
es súper importante.
Y es en todo,
y es súper importante también lo que has dicho,
¿no?
No solo en el desarrollo,
incluso con el producto.
Cómo medir los datos.
Y me parece que los mejores desarrolladores,
ya sean frontend, backend y tal,
son los que,
una vez que han entregado,
lo han terminado y tal,
saben ver el impacto
que están teniendo sobre el producto,
y saben ir algún día a una reunión
e incluso proponer cambios,
porque al final se pueden hacer test a B
y decir,
ostras,
pues esta feature que sacamos la semana pasada,
pues al final parece que no ha funcionado,
pues tengo ideas sobre esto
y la podríamos hacer,
porque al final los equipos de producto,
son eso,
de producto,
son para sacar este tipo de feature
hasta el final,
que luego dices tú,
la iteración es parte del loop de desarrollo
y esto es un no parar.
Totalmente de acuerdo.
Es que también uno de los grandes problemas
que trae la hiperespecialización
es que ponemos mucho el foco en la tecnología.
Yo creo que mucha gente que nos esté escuchando
estará de acuerdo
en que la tecnología no es más que un daño colateral.
El objetivo no es hacer algo tecnológicamente potente
o chulo
o que me sirva en mi carrera.
La tecnología es un medio para resolver un problema
de nuestros usuarios,
de nuestros clientes
o mejorar nuestro producto.
Entonces,
yo,
las personas más maduras técnicamente
con las que he trabajado,
son personas que
cuando proponen hacer algo,
lo proponen para resolver un problema
de usuarios.
No para hacer,
no sé,
para decir,
pues,
he hecho este refactor
o esta implementación chula
o lo que sea.
Eso no le importa a nadie
cómo esté implementado en realidad.
A la gente le importa
que vaya rápido,
que no falle,
que sea seguro,
todo esto.
La seguridad también es otro gran,
otro gran tema del que hablar,
por cierto.
Accesibilidad.
Un montón de disciplinas
que se nos olvidan.
Sí,
que se nos olvidan
y es esto,
no,
está el especialista de accesibilidad
o vamos a contratar
un especialista de accesibilidad
que,
claro,
obviamente,
hay muchas veces
que puede tener sentido esto,
¿vale?
Si en la configuración de los equipos
no existe de ninguna forma
esa figura,
hay que forzar estos cambios
para que ocurran.
Pero,
la empresa,
sobre todo,
tiene que invitar
a que la gente,
pues,
se forme sobre estas cosas.
Entonces,
puedes traer un experto de accesibilidad,
tiene sentido.
Pero no puedes perpetuar
la idea no sería perpetuar esto
en el tiempo.
Tú lo que tienes que hacer
es formar a la gente
para que esta dependencia,
sobre todo externa,
muchas veces,
desaparezca.
No tiene sentido.
Claro.
Es que yo creo,
todo,
todo.
Si traes a alguien así,
porque siempre puede haber una laguna,
¿no?
Tu software no es accesible
o tu software no es seguro
y necesitas serlo
y nadie en tu equipo
es capaz
o tiene la formación necesaria.
Vale,
pues trate a alguien
que te haga una consultoría
o una mentoría
o que haga crecer
a tu equipo en eso.
Pero el objetivo
no es que esa persona
se encargue de hacer eso
para siempre.
Ahí está.
Sino que comparta su conocimiento
y haga crecer a todo el mundo
para que la empresa
sea capaz
de responder
a esa necesidad del producto.
Yo creo
y lo voy a decir
porque todavía no,
a lo mejor no lo hemos expresado claramente,
pero yo sí creo mucho
en el perfil de Full Stack.
He entendido como
esa motivación
o hacia donde
nos deberíamos
estar expandiéndonos nosotros,
¿no?
Intentar,
esto no significa
que no te especialices,
no digo tampoco sea fácil,
pero creo que es
lo que tú decías,
Dani,
que tienes que tener
esa motivación
de querer abarcar
un poquito cada vez más
para poder entender
y poder responsabilizarte
tú y tu equipo
de todas las tareas
que hay en un sprint
o en lo que sea
para llevar una tarea
a producción
y que luego se pueda
medir y todo esto.
Y es que la responsabilidad
yo creo que es
súper importante,
es básica,
porque muchas veces
te puedes encontrar esto
que además
hay incluso batallas
porque al final es
yo he hecho esto
y se lo das al COA
y el COA dice
pues mi tarea es
echar por tierra
si lo ha hecho bien
o lo ha hecho mal,
pues no,
esto no funciona
y todo esto lo devuelve
y todo esto
no tendría sentido
si justamente
todos tuviésemos
ese mindset
de full stack,
esta empatía y tal
y la responsabilidad
en realidad
de que esa tarea salga
sea de todos,
pero al final
tú vas poniendo stoppers
y el de desplegar
y dices
no,
es que hay un problema
en la infraestructura
DevOps,
no se encarga
de desplegar esto,
estoy cansado
de esta gente,
claro,
si fuese tu responsabilidad
lo verías de otra forma,
no te quejarías,
estarías contribuyendo
a solucionarlo.
Es que por eso
yo creo también
que es un error
crear silos
en forma de perfiles
especialistas
o equipos especialistas
o lo que sea,
porque al final
cuando haces eso
la gente
solo se responsabiliza
hasta donde
acaba su frontera
y a partir de aquí
es problema
de otra persona
y los problemas
de verdad
de la empresa
que son los objetivos
de negocio
no son problema
de nadie,
la gente se responsabiliza
pues que de la pipeline
de Jenkins
esté bien
o que los testes pasen
o que el frontend
sea responsive
pero es que eso
no le importa a nadie
y no,
no,
de verdad
eso no es importante
el usuario
no se va a dar cuenta
es que al usuario
le da igual
la pipeline
de continuous integration
que tengas
yo lo que quiero
es comprar mi cosa
o reservar mi hotel
o lo que sea
es que me da igual
como trabajéis por detrás
exacto
entonces
¿cuál es la solución?
creo
ponerle
tanto a personas
como a equipos
objetivos de negocio
todo el mundo
trabaja en la misma dirección
y si al final
hay alguien que dice
no,
yo estoy muy enfocado
yo que sé
en ganar milisegundos aquí
vale,
¿cómo obedece esto
a los objetivos
que tenemos todos?
de ninguna manera
a lo mejor sí
a lo mejor sí que obedece
pero de ninguna manera
pues no se hace
y punto
y si no te gusta
pues vete a otro sitio
donde el objetivo sea
hacer el código bonito
o cualquier otra cosa
que a ver
que normalmente
todo esto tiene respuesta
a veces cuesta verla
¿no?
pero todo tiene respuesta
a la necesidad del usuario
¿no?
o sea
hacer el código bonito
bueno pues esto responde
a que no estamos entregando
valor lo suficientemente rápido
y que el código no sea bonito
nos está afectando
tres horas a la semana
en solucionar cosas
pero el mindset ya es diferente
y no lo ves desde el prisma
de tu especialización
claro
exacto
para que quede claro
no he querido decir
que hacer el código bonito
no sea importante
no, no, claro, claro
sí, sí
yo he entendido
eso tiene un
bueno pero para que quede claro
que luego la gente ya sabe
cómo es
que quede claro
que esto tiene
igual que escribir test
igual que hacer
clean code
igual que buenas prácticas
todo esto obedece
a algo
no es un fin en sí mismo
es un driver
para conseguir
la excelencia
en la eficiencia
del proceso
de entrega de software
exacto
es que tenemos
o sea
tenemos que pensar
que nuestro software
hace lo que tiene que hacer
pero tiene que ser algo
a escalable
tiene que ser mantenible
tenemos que asegurarnos
que es capaz
de evolucionar
con el tiempo
o sea
hay un montón
de cosillas
volviendo al tema
de stack
entonces
alguien
ahora nos deben estar viendo
y escuchando
y nos están diciendo
pero qué pasa
que yo me quiero especializar
en una cosa
yo soy un crack
en javascript
y ahora qué quieres
que me tenga que
que no quiero
que no
o es imposible
no me entra
backend
puff
que le diríamos
porque yo le diría
a ver
abre tu mente
no te pongas así
está bien
no está bien
yo creo que la especialización
es un camino
de carrera profesional
válido
tampoco nos engañemos
y más hoy en día
lo que sí que creo
claro y más hoy en día
porque hay tanto
que aprender
en cada craft
que
tienes años de recorrido
para llegar a dominarlo
y luego van saliendo
cosas nuevas
y te tienes que ir
actualizando
pero sin perder de vista
cuál es tu objetivo
como
persona que desarrolla
producto
y tu objetivo
es pues contribuir
al equipo
con tu conocimiento
y habiendo ese camino
pues también creo
que hay otros
que son válidos
y el camino
de ser full stack
o aprender
lo necesario
de producto
de testing
de datos
de backend
de infraestructura
para comunicarte mejor
con el resto
de la gente
y entender
cuáles son sus problemas
y cómo trabajar juntos
eso no hay que perderlo
de vista
y eso tiene que estar ahí
otra cosa
que yo diría
estoy totalmente de acuerdo
o sea la especialización
tiene sentido
y de hecho
yo creo que nadie
puede estar en contra
pero por más que te especialices
creo que no es imposible
ni inviable
que puedas
expandirte
de forma horizontal
no tenés
a la vertical
de toda la experiencia
pero
eso solo suma
¿sabes?
nunca jamás
eso resta
nunca
nunca he visto un caso
que resta
y fíjate
un caso
que la gente
de Fronten
conocemos mucho
Redax
esta librería tan popular
de gestión de estado
en React
la idea de Redax
nace
de cosas
que se hacen
en el backend
de event
driven development
de gestión de eventos
y de cosas
que se hacen
en arquitecturas
de backend
si no
no habría sido
posible Redax
entonces
el saber
al final
no ocupa lugar
si tú
observas
cómo se hacen
las cosas
en otros entornos
a lo mejor
acabas cogiendo ideas
para resolver problemas
que tienes en el tuyo
entonces
ahora otro tema
porque antes
estaba leyendo
Twitter
y Nuria Coates
que estuvo por aquí
en el state of CSS
comentaba
un tweet
de Toby Lut
que decía
algo así
como que
bueno
que no deberían existir
los frontend developers
más allá
de contextos
de Super Junior
que todos
esos frontends
deberían ser
deberían conocer
todas las capas
y construir
y ser efectivos
y tal
y Nuria comentaba
sí
todos los desarrolladores
deberían saber
todas las capas
y tal
pero solo voy a mencionar
los frontends
porque patatas
y esto es verdad
esto es una cosa
que me sorprende
y no sé por qué
de que cuando hablamos
de full stack
los full stack
tienen que ser los frontends
sabes que es como
que los frontends
son los que tienen que saber
de backend
tienen que saber
de frontend
tienen que saber
de todo
pero como que a los backend
por ejemplo
los backend siempre están
normalmente
no todos
pero muchos backend
jajaja CSS
ah que vas a pintar
colega
jajaja
como estoy
desde un estado superior
no tengo por qué aprender
a pintar cosas
y eso sí que es una cosa
que me sorprende
lo que hemos dicho
no es
o yo al menos
bueno estoy convencido
que estamos
de acuerdo
esto no es una cosa
de frontend
no es una cosa
de frontend
de hecho
no es ni de desarrollador
de javascript
ya sea backend
frontend
estamos hablando
hasta de Qash
creo que tampoco
o sea no estaría mal
hablar de product owners
incluso
no creo que sea
algo negativo
que un product owner
o sea todo lo contrario
que un product owner
sepa desarrollar
o incluso haga
pre-programming
no me parecería mal
una persona de marketing
y los backend
por supuesto
porque tienen una ventaja
que ya saben programar
por lo tanto
su curva de aprendizaje
de saber desarrollar
tecnologías web
o sea
no tienen excusa
y que el CSS sea menor
a menos
me lo parece
cuando es la capa
justamente de presentación
que toca el usuario
totalmente de acuerdo
totalmente de acuerdo
con el comentario
de Nuria
con el tuyo
es algo de lo que se habla
mucho en frontend
incluso bueno
nosotros como somos frontend
pues nos elegimos
más a un público
que hace frontend
pero sí que es verdad
que es a lo mejor
la gente de backend
la que sí que se cierra
más en banda
y dice no
yo CSS no hago
y creo que es una pena
porque la gente de backend
que está muy acostumbrada
a trabajar
con opciones
de orientación a objetos
puede aportar mucho
a buenas estructuras
de CSS
a cómo hacer estilos
que se compongan bien
que tengan responsabilidades únicas
y todo este tipo de conceptos
que también vienen
a la hora de diseñar
una buena librería de estilos
es que es tan importante
no sé
no sé cómo los podríamos convencer
para que no existiese
este tipo de chistes
pero yo animaría
que abriesen
que abriesen en el espectro
no pasa nada
hay otro tema
que por el que
mucha gente
a lo mejor
le crea
esta sensación de rechazo
al concepto
de ser full stack
que es el hecho
de que
muchos bootcamps
creo ¿no?
cuando estás aprendiendo
cómo se venden
y cómo se publicitan
se publicitan justamente
de full stack developer
¿no?
vas a salir siendo
full stack developer
y al final
el bootcamp
pues a lo mejor
tiene sentido
en cuanto
ves diferentes capas
a lo mejor
no todo
el full stack
porque a lo mejor
es lo que tú decías
¿no?
no se ve tanto
el producto
o cómo medir
después el producto
cómo hacerte saber
y cosas así
¿no?
que al final
cuando hablamos
de full stack
creo que nadie
sabe exactamente
qué significa
el full
el full
¿qué significa?
back and front end
back and front end
co-op
back and front end
co-op product
observability
luego data
bla bla bla
si hay aplicaciones
móviles también
base de datos
también
eventos
infraestructura
también
exacto
yo creo que el tema
de los bootcamps
los bootcamps
yo creo que te preparan
muy bien
para empezar
a trabajar
en una empresa
para pasar
un proceso de selección
y empezar
con tu carrera
pero obviamente
no es ni mucho menos
el fin del camino
y
y lo que decíamos antes
de que mucha gente
reniega del concepto
de full stack
y hace poco
hubo una polémica
en el
slack de barcelona
engineering
en el que alguien
lanzó la pregunta
de oye pues
tiene sentido
el tema de los full stack
y tal
y hubo como 200
y pico respuestas
y mucha gente decía
es imposible
ese full stack
es imposible
es algo que
es inconcebible
porque o eres bueno
en una cosa
o eres bueno
en la otra
yo creo que es un camino
y tanto si vienes
de un bootcamp
como de una carrera
pues a lo mejor
en una carrera
pues ya has andado
parte del camino
y en un bootcamp
has andado un poco menos
pero
al cabo de unos años
y tener exposición
a diferentes escenarios
diferentes compañeros
y tipos de proyecto
vas a ir adquiriendo
ese conocimiento
nunca vas a ser
super bueno
en todo
obviamente
a no ser que seas
un mega crack
y todo lo entiendas
a la primera
pero bueno
es un camino
que hay que recorrer
sí que me gusta
lo que proponen
los bootcamps
prefiero un bootcamp
full stack
que un bootcamp
solo frontend
porque creo que
engaña
y a lo mejor
la gente empieza
haciendo una cosa
y se especializa
en otra
o
está bien que se vea todo
que se vea todo
el producto
en tu vent
y que la gente
que salga del bootcamp
pues sea capaz
de aportar una solución
de principio a fin
una cosa que me parece
interesante sobre esto
es que claro
hay que tener en cuenta
que hay veces
que están apareciendo
herramientas
que facilitan el desarrollo
y están acabando un poco
con ciertos perfiles
no acabando
pero que a lo mejor
sí que los pueden poner
en cierto peligro
por ejemplo
oversell
ya no te tienes que preocupar
tanto de la infraestructura
si eres una persona
que se especializa demasiado
seguro que vas a tener trabajo
pero en ese aspecto
oversell
te puede quitar
un trozo
de tu especialización
de golpe
por ejemplo
en backend
pues ahora tienes
un montón de SaaS
súper interesantes
donde te puedes hacer
un backend fácilmente
con una UI
quien sabe
si el día de mañana
en frontend
pues tenemos también
con Figma
y haces los componentes
que no significa
que esas especializaciones
vayan a desaparecer
pero creo que
puede ser más interesante
de cara a tu desarrollo
personal y experiencia
a lo largo de los años
si vas abriendo puertas
porque de esta forma
pues tienes más posibilidades
de mantener tu puesto
o optar
a diferentes posiciones
¿vale?
porque si te especializas
justamente en una cosa
y resulta que de repente
pues si es una tecnología
y de repente desaparece
esto lo he visto
vamos
80.000 millones de veces
en la época de .NET
pues ¿cómo se llamaba
esta?
Link
Link era un lenguaje
para hacer consultas
a base de datos
a cualquier base de datos
en realidad
pues la verdad
es que era
súper interesante
por allá en 2015
no sé ahora
la verdad es que me he despegado
pero que había gente
que decía
no esto es el futuro
y se especializaba ahí
es brutal
y ahora no sé
de qué se da de su vida
pero es que
es un ejemplo
que a lo mejor
ahora lo está petando
Link Queue
y yo aquí
pues ahora
a lo mejor
están aquí hablando contigo
bueno sé
tú hacías Link Queue
tú utilizabas
joder
yo a mí me dio muy fuerte
con Link Queue
no y seguro que era brutal
pero por muy brutal
que sea algo
muy brutal
por ejemplo React
en algún momento se va a acabar
a mí React me encanta
pero
torres más altas han caído
torres más altas han caído
y no porque caigan
y tengan que caer
sino porque
la historia nos enseña
esta es la ingeniería
de software
al final
este chiste de
es que sale en framework
de javascript
nuevo cada semana
lo cual no estoy de acuerdo
pero esto en realidad
lo que nos enseña
es que la ingeniería
de software
al final
es lo que tú decías
que es solucionar problemas
y lo que lo vamos a hacer
es de la forma más eficiente posible
y vamos a aprender
de nuestros errores
y vamos a aprender
de cómo hacerlo cada vez mejor
y de la misma forma
que al final llegarán
y haremos los coches eléctricos
y los haremos más eficientes
pues también el desarrollo
de software
lo haremos más eficiente
y lo haremos mejor
entonces a lo mejor
dentro de 10 años
no está React
está Svelte
está lo que sea
y lo hace de una forma
diferente con otro paradigma
porque resulta que ha tenido
más sentido
a lo largo de la experiencia
que hemos tenido
pero es que pasa en todo
yo creo que es la ley
de vida
la selección natural
o como le llames
es que
llegará un momento
que no haya conductores
de autobuses
ni de metro
ni de trenes
porque son autónomos
ni taxistas
y qué vamos a hacer
vamos a frenar la evolución
para mantener eso
al final
las cadenas de logística
cada vez hay más robots
¿por qué?
porque no cometen errores humanos
porque son más rápidos
y en el desarrollo
hacen lo mismo
llegará un momento
que hacer una UISA
arrastrar y colocar cosas
y ya no haya que desarrollarla
y ya empieza a haber
soluciones de no code
para implementar
hasta un API
todo esto va a desaparecer
porque el software
es un daño colateral
y lo que realmente
tiene valor
es resolver problemas
exacto
y no tanto
que en qué tecnología
lo haces
en fin la tecnología
es un medio
que te está dando
justamente para resolver
ese problema
de la mejor forma posible
¿nos está quedando
este final ya
un episodio
de Black Mirror?
seguramente
seguramente
seguramente
ahora yo
ostras yo Black Mirror
mataría por tener
las lentillas
de Black Mirror
estas que
que puedes rebobinar
y las puedes enchufar
a la tele
mataría por esto
necesito esta tecnología
full stack
últimas palabras
full stack
nada
que yo creo
que no
no hay que
etiquetarse
ni marcarse
barreras
yo creo
que es importante
entender
por qué
hacemos las cosas
por qué las empresas
están intentando
ser ágiles
y cuando
allá
el pase de moda
que le queda muy poco
para pasar de moda
que se quede el pozo
la idea que había detrás
de por qué se empezó
a hacer esto
y nos dejemos
de etiquetas
de silos
de fronteras
y tengamos la mente
en lo que
tiene que estar
que es
en ganar dinero
o salvar el mundo
o resolver problemas
o lo que sea
que haga tu empresa
y cómo tú
como individuo
que tiene un conocimiento
puede contribuir
a resolver ese problema
y ya está
y esta sería un poco
mi idea
tu alegato
al final
muy bien pues
muchas gracias Dani
por pasarte por aquí
un ratito
y hablar
de esta charla
tan interesante
espero que
les interese también
a todos los que nos han visto
y nos han escuchado
nos vemos
pues en el siguiente
muchísimas gracias
a todos por vernos
hasta luego
un placer
chao
adiós
y es el hecho
de que
me he perdido
no sé qué iba a decir
es que estaba leyendo
aquí a mí
corten
corten
no sé
que
claro
no
no
no
no
no
no
no
no
no