Y vamos con Dani, que así intentamos ajustar un poco los horarios.
Así que vamos con Dani de la Cruz, que es Team Lead en Datadoc.
Espero haberlo dicho bien, porque siempre que le digo si es Tech Lead, Team Lead,
siempre lo digo mal.
Creo que esta vez lo he dicho bien, me lo ha apuntado aquí, justamente en la cerveza.
Mira, Team Lead, ¿vale?
Bueno, pues es Team Lead en Datadoc.
Es un amigo que casi familia, que me lo aprecio mucho, me lo quiero un montón.
Sé que es un profesional como la copa de un pino
y estoy seguro que os va a explicar un montón de cosas interesantes.
Su charla se llama Tu Trabajo, no es escribir código y...
Hola, ¿qué tal, Dani?
Hola, ¿qué tal? ¿Cómo está la comunidad hoy?
Pues bien, bien. Están...
Uy, me estoy escuchando yo mismo.
Bueno, me voy ya.
No pasa nada, no pasa nada. Me voy ya.
Me voy ya. Te dejo aquí para que le das cañita.
Bueno.
Suerte.
Venga.
¡Ay!
Ahora.
Bueno, aprender a programar es la llave que abre la puerta de entrada
para trabajar en la industria tecnológica.
Pero, ¿nuestro trabajo consiste realmente en escribir código?
¿Qué hay más allá de aprender un lenguaje o framework y conseguir tu primer empleo?
Mucha gente acude a mí tras llevar dos o tres años trabajando como programadores.
Sienten que ya conocen el lenguaje con el que trabajan
y que dominan las herramientas que utilizan en el día a día.
Pero llega un punto en el que se preguntan, ¿y ahora qué?
¿Qué tengo que hacer para llegar al siguiente nivel?
Yo siempre les respondo lo mismo que te digo ahora a ti que estás escuchando esta charla.
¿Por qué necesitamos a gente para que programe?
Seguramente estás pensando que para desarrollar productos de software como aplicaciones, webs, ¿verdad?
Pero, ¿por qué el mundo necesita el software?
Te voy a decir una cosa.
La gente no necesita el software.
El software existe porque resuelve problemas y satisface necesidades.
Desde encontrar a gente con la que ligar hasta ayudar a un médico a diagnosticar un cáncer.
El software nos da superpoderes.
A la gente no le gusta el software, sino lo que es capaz de hacer con él.
Fíjate si estoy convencido que te diría que muchas veces los problemas se resuelven sin apenas escribir líneas de código.
Déjame que te lo explique con varios ejemplos basados en mi propia experiencia.
Empecemos por el caso de la aplicación de administración.
Las empresas que venden productos o servicios online normalmente tienen una aplicación de administración
para gestionar el contenido que los usuarios pueden consumir.
Productos, viajes, reservas de vuelos, hoteles, lo que sea.
La interfaz de usuario suele estar basada en formularios y listados.
Así que como parece algo sencillo, es muy frecuente que se desarrollen internamente.
Los usuarios suelen ser un equipo de administración que gestiona el contenido y lo mantiene actualizado.
Bien, pues ¿cómo se te queda el cuerpo si te dijera que el 82% de las aplicaciones de administración internas
se pueden reemplazar por un Excel?
¿Qué pasa? ¿Que no te lo crees? ¿Quieres ver la fuente?
Pues aquí tienes una, la fuente de Neptuno.
Pedazo de fuente, preciosa.
Es broma.
En realidad el dato me lo he inventado,
pero está basado en ejemplos reales que he visto con estos ojitos.
Déjame contarte una historia.
Hace poco estuve trabajando en un equipo que gestionaba una de estas aplicaciones de administración.
Nos pidieron implementar con urgencia una funcionalidad para hacer actualizaciones masivas de contenido.
Cuando la analizamos, nos dimos cuenta de que tenía una gran complejidad.
Nuestra aplicación web de administración y nuestra base de datos no estaban preparadas para ese volumen de operaciones.
Además, con el tiempo que nos habían dado, era prácticamente imposible llevarlo a cabo.
¿Qué hicimos?
Pedimos hablar con los usuarios de operaciones para encontrar una solución.
Y al hacerlo, nos dimos cuenta de una verdad que nos dejó con la boca abierta.
En realidad, no usaban nuestra aplicación para casi nada.
Lo que hacían la mayoría de las veces era exportar los datos, llevárselos a Excel y volverlos a importar.
La aplicación web que habíamos hecho para ellos no era eficiente.
Por eso evitaban usarla.
Esto fue un shock.
Nadie se había parado a escuchar a esos usuarios
y la empresa había invertido muchísimos recursos en hacer una aplicación para algo que podían haber resuelto en Excel.
¿Qué desperdicio, no?
¿De qué sirve el código que habíamos escrito si luego nadie lo utilizaba?
¿Qué hicimos para implementar la actualización masiva?
Mejoramos el proceso de importación y exportación,
añadimos algunos datos que faltaban y lo hicimos tolerante a errores.
Nos centramos en mejorar el flujo de trabajo que ya les funcionaba.
Escribimos código, sí, pero mucho menos y más rápido de lo que se esperaba al principio.
¿Cuál fue la clave?
Entender a nuestros usuarios y encontrar la forma más económica de resolver su verdadero problema.
Ese fue el verdadero aporte de valor de nuestro equipo.
Desarrollar productos de software a veces tiene que ver con la decisión de comprar o construir.
Entre hacer algo de cero y utilizar un Excel hay soluciones intermedias.
En este caso, como Forest Admin o Airtable, que te ofrecen un software como servicio.
Puedes pensar que comprar un producto tiene un coste en forma de cuota mensual, por usuario, por consumo,
pero recuerda que construir software desde cero también tiene un precio.
Hay que pagar sueldos, infraestructura, está el coste de oportunidad,
el tiempo que tardas en tenerlo terminado frente al valor de pagar para tenerlo mañana mismo.
Además, que no dudo de tus capacidades, pero seguramente no vayas a hacer una aplicación que funcione mejor que Excel.
Nadie lo ha hecho en 40 años.
Si hay algo que ya existe y te sirve, ¿para qué intentar imitarlo?
Yo sigo la siguiente regla.
Si tu empresa no va a ganar dinero ofreciendo eso que quieres construir como servicio
y ya existe una empresa que lo hace, normalmente es mejor comprar que construir.
Por ejemplo, si te dedicas a reservar hoteles, ¿por qué deberías invertir tiempo y recursos
en una herramienta interna de gestión de facturas?
¿No deberías centrarte en ofrecer la mejor experiencia de reservas de hoteles del mundo?
Esta filosofía también aplica a pequeñas decisiones del día a día que tomamos como programadores.
Déjame contarte otra historia.
El caso del Design System.
En otro lugar, una empresa quería hacer un rediseño de su producto.
El equipo llevaba ya un tiempo sin avanzar demasiado porque estaban discutiendo
si valía la pena crear su propio Design System.
Cuando pregunté cuál era el tamaño del equipo me dijeron
6 personas.
¿Cuál crees que fue mi consejo?
Tres palabras.
No os liéis.
Tenían un producto sencillo donde el diseño tenía que ser funcional y punto.
Una empresa pequeña solo debería invertir en su propio Design System
si el aspecto gráfico es parte de su propuesta de valor.
Pero si no lo es y además tiene pocas manos, hará bien en dedicar sus recursos
a lo que realmente importa.
A veces hay cosas que nos apetece hacer como programadores porque son técnicamente interesantes
o un desafío.
pero si en el contexto no tienen sentido, nuestra responsabilidad es encontrar una solución
adecuada a ese contexto, recursos, tiempo disponible, etc.
A este cliente le recomendé utilizar un Design System ya existente y desbloquear la situación.
Y he puesto como ejemplo el Design System pero también aplica a otras decisiones,
autenticación, routers, validación de formularios.
¿Qué hace a tu aplicación tan especial para resolver un problema ya resuelto?
¿Tienes capacidad para mantenerlo?
A veces puede tener sentido, pero siempre hay que hacerse la pregunta
porque algunas de estas decisiones pueden influir en el éxito de un proyecto.
Algo que también nos pasa mucho cuando nos pensamos que nuestro trabajo es escribir código y resolver
problemas que no tenemos y probablemente nunca tengamos.
Mi última anécdota, el caso del prototipo va de esto.
Una vez acudió a mí una empresa y me dijeron que querían hacer un prototipo para un producto nuevo.
Su idea era crear una especie de Netflix pero para un grupo de usuarios muy concretos.
Antes de acudir a mí les había asesorado a una consultora y querían una segunda opinión.
La consultora les dijo que necesitaban contratar varios servicios de infraestructura en Amazon Web Services,
almacenamiento, base de datos, vídeo en streaming, autenticación, vamos, el pack completo.
Estaban preocupados porque tenían miedo de invertir mucho dinero y tiempo en construir algo que parecía muy complejo.
Y les pregunté, ¿pero cuántos usuarios tenéis?
Y me respondieron, ninguno.
Ahora mismo solo queremos ver si podemos conseguir inversores.
Y les dije, cuidado porque a lo mejor estáis solucionando problemas que nunca vais a tener.
Mi forma de ayudarles fue convencerles de que no necesitaban hacer nada de eso.
Todos los productos pasan por al menos una fase de descubrimiento en la que intentas averiguar si lo que estás construyendo tiene sentido y aporta valor.
En esta fase tienes que estar preparado para validar o descartar la idea.
Que tu idea no le interese a nadie siempre es una posibilidad.
Tienes que estar preparado para tirar lo que hayas hecho a la basura.
Por eso les dije que estaba bien invertir lo mínimo, tomar atajos, porque el objetivo era validar si su producto era interesante.
Ya llegará el momento de resolver los problemas de escalabilidad.
¿O no?
Porque la probabilidad de que nunca lo necesites siempre está ahí.
Hay que tenerla presente.
Mi recomendación.
Busca la solución más sencilla para cada situación.
Y no te compliques la vida resolviendo problemas imaginarios.
Ya habrá tiempo de pensar en soluciones a largo plazo.
Y estarás pensando, para Dani, para, me estás liando, entonces ¿cuál es mi trabajo?
Vuelve a hacerte la misma pregunta que te hice al principio.
¿Por qué necesitamos a gente que programe?
La pregunta tenía trampa.
No necesitamos a gente que programe.
Necesitamos a gente que resuelva problemas.
Y entienda cuáles son las necesidades de las personas que van a utilizar su producto.
Que se adapte al contexto.
Y decida cuándo conviene invertir en implementar una solución o utilizar algo existente.
Que ayuda a su empresa a crear soluciones creativas dependiendo del momento.
Que entienda que escribir código tiene un precio.
Piensa en tendencias que ya están aquí.
Como NoCode, editores asistidos por inteligencia artificial como GitHub Copilot.
Estas tecnologías vienen para ayudarte, no para quitarte el trabajo.
Y es que pensar que tu trabajo es escribir código, es ponerte límites.
Es ponerte el sombrero de ejecutar órdenes y no detenerte para entender el problema.
Nuestro trabajo no es escribir código, es resolver problemas.
El código no es el fin, sino que es un medio para conseguir ese objetivo.
Entrenar tu habilidad para resolver problemas es lo que te va a garantizar trabajo en el futuro.
Ya sea escribiendo código o no.
Eso es lo que te pone en valor como profesional.
Muchas gracias.
Y punto.
Ay, Dani, no sé si te puedes poner unos cascos para no escucharme.
Me pongo unos cascos.
Me pongo unos cascos.
Sí, sí, que es que me escucho.
A ver, a ver ahora.
Todavía no me escucho.
¿Qué tal? ¿Me oyes?
Ahora mejor, ahora mejor.
Vale, es que ya no me escucho.
Es que se hace con eco y entonces no...
Ahora bien, ¿me escuchas?
Ya está, ya está.
Muy bien.
Dani, muy bien.
Muchísimas gracias.
Le ha gustado mucho a la gente del chat.
Qué buenos consejos.
Es que es verdad, ¿no?
Que mucha gente, la gente se cree que es que es programar, programar, programar, todo el día programar.
Y, oye, que no pasa nada que utilices una herramienta de no code, especialmente si te va a quitar trabajo,
pero para que te puedas enfocar a otro sitio que te va a marcar realmente la diferencia
y que no intentes solucionar cosas, problemas que todavía no tienes, ¿no?
Que a veces nos adelantamos de una forma muy loca.
Bueno, ¿qué tal?
A ver, ¿alguien tiene una pregunta para Dani?
Aceptamos una pregunta.
La mejor pregunta, ¿eh?
Hay gente que me está pidiendo un libro de Git, me dice, quiero mi libro de Git.
Yo he venido a que me den mi libro.
Sí, sí, pero es que parece ser que se ha caído el impact con tan mala suerte que es que ni siquiera se podría canjear.
Es que da 502.
Cuando se arregle, arreglaremos y le daremos todos los libros y le daremos un extra para compensar.
Vale, a ver, dice, Dani, ahora me di cuenta cómo puedo empezar a pensar más en soluciones y menos en programación.
Ahora que me di cuenta, no es una pregunta, ¿no?
Yo diría, no pienses en soluciones, piensa en el problema, abraza el problema, dedica más tiempo a entender el espacio del problema y eso te hará llegar a las mejores soluciones.
A veces es como los ejemplos que he puesto, ¿no?
Hay veces que te vienen con un requerimiento que es en forma de solución, pero si te paras a entender cuál es el problema y realmente cómo tus usuarios están utilizando tu producto, a lo mejor llegas a otra solución mucho más rápida, más fácil de hacer, más económica.
Claro, y prueba la solución antes de ponerte y perder todo el tiempo, ¿no?
Como la chica esta que estabas comentando la historia, ¿no?
De, bueno, bueno, pero si esto no has testeado con nadie y tú quieres montar aquí algo escalable, vamos a llamar a la gente de Codely.
Exacto.
No tiene ningún tipo de sentido, no tiene ningún tipo de sentido.
Vale, ¿cuál es el límite sobre pensar y generar una solución?
Ostras, no entiendo la pregunta.
A ver, sí que es verdad que lo que tampoco puede pasar es que caigamos en análisis-parálisis.
Yo creo que una vez entendemos cuál es el problema y hemos estado un tiempo invirtiendo en eso, hay que probar cosas.
Hay que probar cosas, fallar, equivocarte, iterar, intentar poner algo en producción y software en manos de los usuarios lo antes posible.
Y van a ser tus usuarios quienes te digan si estás acertando o no y los que te vayan marcando cuál es el camino.
Claro, totalmente.
¿Crees que la toma de estas decisiones diferencian a un senior de un middle?
Buena pregunta.
Está interesante, ¿eh?
Yo creo que sí.
Y justo empezaba la charla diciendo esto.
Mucha gente que acude a mí en las mentorías o gente con la que trabajo me dice, oye, ¿cómo llevo a ser senior? ¿Qué tengo que aprender?
Y normalmente su pregunta está orientada a qué tecnología o qué lenguaje o qué arquitectura tengo que aprender.
Y yo les digo, bueno, si ya sabes programar, ya tienes una habilidad troncal lo suficientemente sólida, aprende a ayudar mejor a tu equipo, a ayudar mejor a tu empresa, a ir teniendo impacto más allá del código.
Por eso la charla, ¿no?
Exacto.
Tu trabajo no es hacer código.
Totalmente. Bueno, Dani, pues muchísimas gracias. Muchas gracias por la pedazo de charla. Gracias por pasarte. Y nada, feliz día del programador y la programadora.
Pues nada, muchas gracias a ti por organizar todo esto.
Te mando un abrazo enorme. Cuídate mucho.
Un abrazo.
Crack. Hasta luego.
Adiós.
Chao.
Bueno, pues ahí teníamos al bueno de Dani. Muchísimas gracias. Pero habéis visto qué interesante es el hecho de que, aunque hablemos de programación, aunque hablemos de desarrollo, no tenemos que estar todo el día codificando y no tenemos que ver justamente el no-code y estas cosas como algo que te va a quitar el trabajo.
Sino como algo que te va a permitir enfocarte realmente en las cosas que marcan la diferencia. Así que ya sabes. Vamos a hacer ahora el sorteo del teclado Keychron, ¿vale?