¿Cómo se hace?
La tramoya del podcast.
¿Cómo funciona esto?
Bueno, son 20 espectadores simultáneos.
Qué bonito.
20 personas que han pensado que esta mañana,
en lugar de ir a la iglesia,
es mejor hablar de front-end.
Bueno.
10X iglesia.
Exacto.
Vale, pues ¿qué?
Estamos.
Yo creo que Jebser ya llegará a un día de estos.
¿Le damos?
Dale, caña.
Ah, sí, ya está grabando.
Qué maravilla.
Vale.
Me voy a colocar así.
Aquí, delante de todo el mundo.
Os voy a silenciar a todos.
Este era el botón.
Bueno, empezamos.
Bienvenidos a todos y a todas a una nueva entrega de What the Front,
tu podcast de front-end en castellano.
¿Qué digo de podcast?
Tu 10X podcast.
Y por eso hablamos de los 10X engineers.
¿Qué son?
¿Existen?
¿Son unicornios?
¿Qué opinamos sobre ellos?
¿Y qué opinas tú?
Pues si quieres saberlo, quédate y no te lo pierdas.
Pero claro, para hablar sobre 10X engineers, pues qué mejor que tener las 10X compañías que tengo aquí.
Y así que le doy la gran bienvenida primero a Carlos Villuendas, que está aquí de nuevo en los micrófonos de What the Front.
¿Cómo estás, Carlos?
¿Cómo te encuentras?
Ay, súper bien, súper contento de estar aquí otra vez con vosotros y con un tema tan interesante como el 10X engineer.
10X.
¿Te encuentras esta mañana con 10X energía para hablar de eso?
10X energía.
Me acabo de comer un bocadillo súper rico que me ha dado 10X ahí de azúcar, ahí bien metido.
Pues hablando de 10X, de 10 en 10, y ahora pues a 100X tenemos aquí a Daniel de la Cruz, mi gran amigo y compañero.
¿Cómo estás?
Muy bien, encantado de estar aquí otra vez contigo en este fenomenal podcast.
¿Es 10X podcast?
Es un 10X podcast.
Para 10X también toda la gente nos está acompañando en YouTube, en directo.
Tenemos a 22 espectadores, muchas gracias a todos.
Los voy a leer un poco en diagonal porque os tienes un poco lejos, ves a él, Rodriguito.
Rodriguito seguramente es alguien muy joven, le vamos a mandar un saludo por todo lo que hemos hablado en la previa del directo.
Alex Marlés, también tenemos a José Lorenzo, Daniel López, Supersonic, Gabe, Dani Paredes.
Todos sois 10X, muchas gracias.
Ay, Dani, menudo tema, 10X.
Es un temazo, ¿eh?
La multiplicación, tal cual.
10X developers, animales fantásticos y dónde encontrarlos, ¿no?
¿Dónde se encuentran, no? Estos 10X, ¿dónde los encontramos?
¿Dónde nos hemos encontrado nosotros?
Sería la primera pregunta esta semana.
No sé, ¿tú te has encontrado alguna vez un 10X developer?
Porque yo sí, unos cuantos.
¿Ah, sí?
Sí.
¿Y no eras tú uno de ellos?
Pues podría ser que yo haya sido alguna vez.
Durante un tiempo.
Pero ya lo he dejado.
Ah, lo has dejado.
Lo he dejado.
¿Porque cansaba mucho o porque no creías en ello?
¿O te diste cuenta que no era el camino hacia la sabiduría y la iluminación?
Yo creo que poco a poco me fui dando cuenta de que no era el camino hacia la sabiduría.
Pero bueno, ya iremos hablando.
¿Encontraste tu camino, pequeño Jedi?
Encontré mi camino.
¿Y tú has sido 10X, Carlos?
Uy, no creo.
¿O lo sigues siendo?
Porque claro, estamos partiendo de la base que ninguno aquí somos 10X o lo somos.
O lo sí lo somos.
Yo creo que el 10X, según la lista del señor este indio, yo por lo menos no encajo.
Quiero pensar que has hecho investigación y te has asegurado que ese hombre es indio.
Parecía indio, ¿no?
¿El nombre?
No era indio.
No lo sé, no lo sé.
Pero ese es el momento en el que…
Pero era una consultora india, por eso Axel…
Vale, vale.
Has hecho…
Has atado cabos.
Vale, vale.
Ahí lo dejamos.
Sí, sí, sí.
Pues vamos a saludar también a Manu Mora, Antonio Luis Gil Rodríguez, que se han apuntado
al chat.
Esperamos vuestros comentarios y opiniones en directo, la vamos a ir leyendo.
Estamos esperando también a un cuarto integrante aquí en esta mesa, que es Jebser Bernardino.
Bienvenido, Jebser… Ah, no, no está.
Porque se está tomando un 10X de tiempo para poder llegar.
Le hemos dicho a las 11 y media.
Me dice, uuuh, qué tarde, si voy sobrao, si voy sobrao.
Sí.
Ya no, ya no va sobrado.
Ya no.
Ya te falta.
Ya te falta tiempo.
Te vas a dejar a deber.
Exacto.
Es ese momento cuando llegas tarde a los sitios, no sé si a vosotros os pasa, en el que…
Yo sé…
Perdón, yo sé de alguien que le pasa.
A mí me pasa mucho.
Sí.
No, por eso yo lo sé.
Yo lo sé.
A mí me ha pasado hoy también.
Sí.
Yo voy a hablar desde mi experiencia, ¿vale?
Pero yo sé a veces cuando salgo tarde y dices, es ese momento en el que sabes que por muy rápido que vayas, vas a llegar tarde.
Entonces dices, ¿para qué corro? O sea, ya jamás voy a ir hacia atrás en el tiempo.
Claro.
Entonces ya es minimizar, ¿no? El golpe.
A mí me pasa que es un poco mágico ese momento en el que efectivamente te das cuenta de que vas a llegar tarde y piensas, ostras, hoy no tengo que correr.
Perfecto, me voy a pegar una ducha tranquilamente, me voy a afeitar bien, voy a ir tranquilo caminando, mirando el paisaje, porque en total ya quedo tarde.
Y yo esperando.
No, la última, bueno, la última no sé.
¿Esta semana? ¿Solo esta semana vamos dos a uno?
Eh, es verdad. Dos a dos.
¿Cómo que dos a dos?
Vamos, perdónate, esto ya es algo personal.
A ver, a ver, a ver.
Vamos a ver, no la verdad y así hablamos también de la JS Camp y la CSS Camp.
El caso es que yo el miércoles, queridos oyentes y queridos espectadores de YouTube, yo quedé con Daniel de la Cruz y tengo que reconocer que me quedé dormido tal marmota en la cama, agarrado ahí como garrapata, sin poder desprenderme de tan preciado objeto.
O sea, no podía, no sé, había una fuerza superior a mí y llegué tarde, nada más y nada menos que casi una hora tarde.
Y Dani tuvo el bien, por supuesto, a hacérselo saber a todos sus seguidores de Twitter para que se den cuenta cuán mala persona y amigo...
A los cinco.
A los cinco, ¿de qué cinco? Si tienes 423.000, que lo he visto.
Qué va.
Entonces, el miércoles fue mi culpa, el jueves tengo que decir que a mi pareja le tenían que hacer unas pruebas y llegué tarde por un buen motivo.
Sí.
Pero entonces Dani consideró a bien devolvérmelo el viernes.
Pero no fue a propósito.
Ah, no, comprarse un móvil es sin querer, ¿no?
Tú vas andando, tú vas...
Va por ahí, vea, me voy a comprar este pedazo de pepino.
Sin querer.
Sin querer.
¡Ah, se me han caído 500 euros al suelo! ¡Oh, Dios! ¡Ostras!
Pero no llegué tarde por eso.
Ah, ah.
¿No? Es que no me acuerdo ahora por qué llegué tarde.
Pero en parte...
Ya que llegaba tarde, pues pensé, pues ya que llego tarde...
Qué grande.
Me paso a comprar el móvil y ya está.
Muy bien, me encanta.
Y entonces hoy mismo ha dicho, bueno, también con excusa. Yo también tenía excusa el jueves.
Sí, hoy tengo algunas cosas que mi niña ha estado con fiebre toda la noche, he dormido muy mal, le mando un besito desde aquí por cita.
10x besitos.
10x besitos.
Y a mi señora también, que está ahí cuidando de ella.
Y me ha dejado venir aquí.
Muy bien.
Muchísimas gracias, Cris. Eres la mejor.
Eres la mejor.
Eres la mejor.
También tenemos a Manu Mora, no sé... Sí, Manu Mora ya lo he dicho. Pablo Rocha, hola. Aquí un 1x.
Y Arnau Rius, hola, cracks.
Pues bienvenidos, 24, estáis ya.
Y dando vuestras opiniones.
Vamos a hablar también esta semana justamente de estos problemas que hemos tenido de agenda, Dani y yo.
Ha sido también en parte porque hemos asistido a la JS Camp, a la CS Camp. Hemos estado los tres.
Y bueno, pues ya que estamos aquí, pues estaría bien hablar un poquito de la conferencia que en Barcelona no la hacen todos los días.
¿Qué tal, Carlos? A la CS Camp tú no fuiste, fuiste a la JS Camp solo.
Tenía el ticket para ir a la CS Camp, pero me tuve que ir a Madrid por temas de trabajo y no pude ir.
Así que me la perdí completamente, la CS Camp. Solo estuve en la JS Camp.
Así que si queréis comentar vosotros primero la CS Camp.
Bueno, vale.
Uy, perdona, que te había... Es que te he visto que ibas a estornudar y tal y he dicho, hey, ¿has visto?
Bien, bien, era un bostezo.
Vale.
Pobrecito.
Sí, ¿le damos caña a la CS Camp?
Dale, dale, caña.
¿Empiezo yo?
Dale, empieza.
Bueno, no estuvo mal la CS Camp, la verdad. Yo creo que es una conferencia muy cercana y muy amena.
Vinieron grandes ponentes como Harry Roberts y no me acuerdo ahora quién más. No me acuerdo, soy fatal para los nombres.
Hubo un par de charlas que me gustaron bastante. La de Cassidy, no recuerdo el...
Cassie Evans, ¿no?
Cassie Evans, Cassie Evans.
Que de A o la de SVG.
La de SVG.
Muy chula.
Fue increíble esa charla, fue preciosa, muy chula. Lo que pasa es que, así como crítica constructiva para la conferencia, hubo demasiado contenido, para mi gusto, de UX.
Y además de UX, sin explicar cómo aplicas estas mejoras de UX con CSS, que al fin y al cabo la conferencia se llamaba CSS Camp por algo y uno va a aprender cómo aplicar estos patrones con CSS.
Y además hubo como tres charlas que hablaban prácticamente del mismo tema, que es de performance percibido por el usuario y cómo aplicar técnicas de UX para mejorar esta percepción.
Quizá podría haber habido más variedad en este sentido y no tres charlas seguidas hablando de casi casi el mismo tema.
Sí, es verdad que hubo tres que iban de... que no fuesen las cosas tan rápido, ¿no?
De dejar que las animaciones hiciesen que todo fuese más natural.
Y es verdad que hubo tres charlas que trataron este tema y se sintió un poco...
Se sintió un poco repetitivo, ¿no?
Es que en realidad era el mismo tema, desde tres enfoques diferentes, eran tres personas distintas hablando, pero hablando de lo mismo, ¿no?
De hacer microinteracciones, microtransiciones, que todo vaya más fluido, etc.
No sé.
Me faltaron ejemplos más prácticos porque al fin y al cabo, tanto experiencia de usuario como CSS son dos disciplinas lo suficientemente amplias como para dedicarle un track o una conferencia específica.
Y yo personalmente, si voy a una conferencia de CSS, quiero ver técnicas, patrones, herramientas CSS que me abran la mente y que poder aplicar.
Sí. En ese aspecto yo estoy de acuerdo contigo y hubo tres charlas que creo que fueron las que realmente llenaron bastante la conferencia, o ese día de CSS Camp, que fue la de Oliver Turner, creo que sobre fuentes...
Ah, la de tipografías, no.
¿De tipografías? Ah, esa fue la Houdini. Ahora la estoy mezclando, ¿eh?
Creo que Oliver fue la de Houdini, que Houdini está bastante bien, muy interesante.
Yo estaba Jason Pamental, puede ser, que fue la de tipografía, que estuvo muy guay, y la de Casey Evans, que es la de USBG y todo esto.
Exacto.
La de Harry Roberts a mí me gustó bastante, pero coincido que era un tema más de performance, que no sabría ubicarlo, si CSS o JavaScript.
Es que no era ni CSS ni JavaScript, era performance, era HTML, porque al final esto está dentro del estándar HTML. Bueno, está bien, siempre está genial poder ver en directo a gente referentes en el sector como Harry Roberts, pero para ser un día completo de CSS Camp, había muy poco CSS. Esta es mi crítica.
Una, antes que se me olvide, porque es que yo creo que hay que enmarcarla, que es la de escribiendo algoritmos CSS.
Ah, sí.
Fue la última, me gustó muchísimo tanto el formato, como hizo las slides, fue Lara Schenk, es complicado de pronunciar, Schenk. Y estuvo muy interesante, ¿no? Porque es este debate sobre si CSS es un lenguaje de programación o no es un lenguaje de programación.
Sobre esto podríamos hacer un programa un día y invitamos a Carlos Villuendas, que tiene una opinión muy interesante al respecto.
Estoy escribiéndolo, ¿eh? Estoy trabajando en ello. Me dijo, si no puedes hacer, ¿cómo era? Una máquina de Turing.
Una máquina de Turing con un lenguaje no es de programación. Y bueno, estoy ahí con CSS.
Venga, que seguro que puedes.
Es interesante porque la chica...
Básicamente lo que necesitas es un registro de memoria y un bucle.
Bueno.
Así que con eso ya puedes hacerlo.
Ella hizo el FizzBuzz, ¿sabes? Con CSS.
Claro, también es verdad que yo de CSS tampoco estoy muy puesto. Igual a día de hoy ya tienes bucles y tienes cosas de estas.
Ay, ay, ay. Hombre, con CSS y cosas así sí que podría.
Hombre, mira que han entrado alguien por aquí y tenemos aquí en directo... Sí, sí, te están observando.
Hola.
Hola, ¿qué tal?
Acaba de entrar por la puerta Jebser Bernardino. Vamos a ver, vamos a saludarlo. Hola, Jebser, puedes decir hola aquí.
Hola, hola.
Me encanta porque has venido en frío, ¿sabes? Es ese momento en el que es jodido.
Porque estamos aquí todos calentitos hablando. Hola, ¿qué tal? No sé qué.
Entra por la puerta Jebser y dice, bueno, ¿y ahora yo de qué hablo?
Escuche el bucle y dice ese...
Acércate un poquito más al...
Acércate, así. Amórrate, amórrate.
Vale, ahí está.
Aquí tenemos ya a nuestro colega Jebser que le estábamos comentando antes que decías,
uuuh, a las once y media voy sobrado. Voy a venir hasta en bici, me decía.
Hoy vengo tan sobrado.
Entonces tenemos aquí Jebser Bernardino. ¿Cómo estás? ¿Cómo te encuentras?
Muy bien, con mucho calor.
Sí, ¿no? Con calorcito y tal.
Jebser, cuenta un poco a la audiencia, a los oyentes y a los que están viendo aquí en YouTube en directo,
quién eres, de dónde vienes, aparte de venir corriendo desde tu casa de Barcelona.
Bueno, soy programador también y vengo desde Guatemala.
Ahora no ha venido desde Guatemala, ¿no?
Con razón llegas tarde.
Acaba de aterrizar desde Guatemala.
Bueno, trabajo actualmente en Badi, esta aplicación para encontrar pisos como frontend.
Muy bien. Jebser, además, yo coincidimos, Dani y yo coincidimos en Typhoon, una temporada con Jebser,
compañero nuestro, aunque la verdad es que yo no tuve mucha ocasión de hablar mucho con él.
Hablamos más el año pasado que coincidimos en la frontend conf de Polonia y, bueno,
pues nos vamos viendo en conferencias y en meetups y tal.
Y justamente ahora estamos hablando de nuestra opinión de la CSS Camp y ahora íbamos a pasar a la JS Camp.
Así que no sé si quieres estrenar, Jebser, y decir un poco qué te pareció la conferencia,
qué es lo que más te gustó.
Cuéntanos, Jebser.
Bueno, creo que estuvo bien, la verdad.
La calidad de los speakers fue bastante buena.
Creo que el rango de charlas fue desde lo más conceptual a cosas un poco más técnicas,
como la conferencia del B8 o la charla del B8 y del WICMAP y todo esto.
En general me gustó bastante.
Creo que el venue sí quedó un poco pequeñito.
Y bueno, prefiero que ustedes sigan.
Se ha quedado sin palabras.
Es que está respirando bien.
Viene corriendo.
Bueno, es verdad que en la CSS Camp había bastante menos gente,
menos afluencia.
Eran 400 asistentes que lo dijeron.
Y en la JS Camp estaba a reventar.
A veces llegabas tarde al salón y te quedabas sin sitio.
Totalmente, exacto.
Pues hablando de la JS Camp, que a esa sí que fuiste, Carlos.
Ahí no tienes ningún tipo de excusa.
Sí, ahí sí que fui.
Ahí tengo yo cosas que decir.
Pues di, di.
Dice, tengo cosas que decir.
Di, di, ¿qué quieres decir?
A ver, charlas que estuvieron bien.
La de la de B8 estuvo bastante guay.
Yo estoy con la duda que tenía Miguel Ángel,
que también estuvimos, que me pareció una duda súper.
Después de lo que explicaron de los WICMAP,
cuál era el sentido de los MAP,
me pareció una duda súper razonable.
No sé si alguien nos la puede responder,
porque totalmente de acuerdo.
Yo tampoco tengo muy claro ya cuál es.
Si están los WICMAP, por qué utilizar los MAP.
La charla de gestión de errores,
me pareció súper interesante también.
Y bueno, básicamente después las charlas de Kyle Simpson,
demasiado inspiracional, no la acabé de ver.
No sé muy bien cómo articular eso, todo lo que nos decía.
A mí dejó muy descolocado la charla de Kyle Simpson.
No me lo esperaba.
O sea, fue como, ¿what?
Un poquito para que la gente que nos escuche,
pues sepa de qué charla estamos hablando.
Kyle Simpson, quizás mucha gente lo conozca,
por sus libros de You Don't Know, GS.
Pero comentad un poco de qué iba la charla,
qué quería decirnos con la charla.
Porque empezó así, la JS Camp fue la primera charla.
Normalmente la Keynote o lo que empieza...
Sí, fue la primera, ¿no?
Fue la primera.
Pues la Keynote, tú esperas que te hablen de,
pues no sé, de JavaScript,
de cómo lo está apretando,
el estado de JavaScript.
Y fue un poco interesante por lo que dices, ¿no, Carlos?
Porque, ¿qué es lo que nos quería decir Kyle Simpson?
Claro.
Yo, como yo lo entendí, ¿vale?
Yo digo que creo que me quedé bastante descolocado.
Él intentaba decir,
tenemos que hacer una web más empática
para gente que tiene menos recursos
que la media de la que nosotros solemos relacionarnos.
Y tenemos que hacer que nuestro código se adapte
a gente que tiene unas limitaciones técnicas,
tanto de dispositivos como de conectividad
y como de electricidad,
que nosotros ahora mismo seguramente
ni siquiera concebimos.
Lo que nos ha ido muy bien
es cómo llegar a articular todo eso
en el mundo actual, profesional,
tan competitivo,
donde nos cuesta tanto trabajo.
Llegar al estándar mínimo
que para mí hoy en día...
O sea, mi realidad
es que mi mínimo hoy en día
es darle soporte en TNES Progel 11.
Ya sé que es muy bestia,
pero es que es el mínimo
que me están pidiendo.
Entonces, no sabría muy bien
cómo articularlo todo esto.
Claro, yo creo que una cosa que...
De hecho, he leído críticas
o comentándolo allí en la conferencia
porque hay gente que sentía que Kyle Simpson
no tiene esta responsabilidad en su día a día
y entonces como que estaba fuera de la realidad.
Lo que Kyle Simpson también nos está diciendo
era un poco de...
Bueno, tenéis que ofrecer una versión
lo más simple posible con HTML
o incluso dar la oportunidad
o él está incluso proponiendo
alguna feature o un proposal
de que el usuario mismo
pudiera ir decidiendo
con un slider
cómo quiere que sea la...
No sé, cómo de rica
quiere que sea la experiencia
a costa de la performance, ¿no?
Digamos.
Entonces, claro, mucha gente
tuvo dos frases
que yo creo que fueron las que cayeron
más como una dosa.
La primera,
si Google lo hace con Gmail,
¿por qué no lo vas a hacer tú?
Claro, es que esto...
Claro, hay mucha gente que decía...
Es demoledora, ¿no?
Porque está muy alejada
de lo que es la realidad.
Si Google lo hace,
¿por qué no lo haces tú?
Pues porque no sé Google.
Y hay tantas cosas que hace Google
que no hago yo
que podríamos dedicar un programa entero.
Google puede dedicar
un departamento entero
a mantener la versión HTML de Gmail.
¿Por qué?
Porque le compensa,
eso es lo primero.
Y porque tiene recursos para hacerlo
y porque puede,
pero es que además Google y Gmail
son negocios mundiales, globales.
Claro.
Y muchos de los mensajes
que daba Kyle
eran para empresas
que tienen negocios globales,
pero tampoco hay tantas empresas
que tengan negocios de este tipo.
Airbnb, Facebook, Uber...
Y se me van acabando los ejemplos.
La mayoría de los ejemplos
de empresas que conocemos
son muy locales.
En un solo país funcionan,
o incluso en una ciudad
hay un montón de startups.
en Londres, por ejemplo,
que solo funcionan en Londres.
En Londres, claro.
Y esta es la gran mayoría
de gente que estaba asistiendo
a esa conferencia.
Entonces, otra de las frases
lapidarias que tenía Kyle
era
¿Es vuestra responsabilidad
hacer una web
accesible, inclusiva?
Vale.
Es verdad.
Y decía,
no pidáis permiso.
Mejor pedir perdón
que pedir permiso.
Ya os lo he oído.
Ya lo doy yo el permiso.
Esa frase muy mítica.
Dice, hombre, Kyle Simpson,
a ver,
si yo me pongo a dedicar,
invertir mi tiempo
en hacer sliders
para elegir el nivel
de fitos
que tiene que tener
el producto,
pues eso al final
son recursos de la empresa.
Y hay que priorizar
el trabajo que se hace
y a lo mejor
estamos invirtiendo
un montón de esfuerzo
en hacer algo
que funcione muy bien
en Sydney,
muy alejado de los CDNs
y tenemos cero usuarios
en Sydney.
No sé.
A mí,
otra de las críticas
que tengo
de la CSCAM
y de la JSCAM,
no como conferencias en sí,
sino de la gente
que ha venido a dar charlas,
es que sus argumentos
estaban muy poco
respaldados con datos.
Es decir,
está muy bien decir
que hay que hacer
una interacción más lenta
para que el usuario
la vea mejor
o...
Pero muéstrame los datos,
muéstrame lo que pasa
cuando haces una página
con más microinteracciones,
cuando inviertes ese esfuerzo,
cuál es el retorno
de esa inversión.
Y si no lo haces,
lo único que queda
es un argumento
basado en tu autoridad,
tu autoridad como ponente
que está dando una charla
o una conferencia
y poco más.
Puedes tener razón
o no
o tu opinión
puede estar sesgada.
¡Guau!
Y ahí lo deja Dani.
Y esto lo venía
todo preparado
y pues no ha dormido
por la noche
porque venía
con todo esto preparado
con un saco
y ha dicho
le voy a soltar aquí
y estoy de acuerdo.
La verdad es que
hubo unas cuantas frases
en ese aspecto
como por ejemplo
la de Kyle,
lo de Google
y todo esto,
lo de las microinteracciones,
lo de las animaciones,
faltó ese tema de datos,
¿no?
Porque fue como
bueno,
yo creo que esto
y va a funcionar.
¿Tú qué piensas?
Jebser,
cuéntanos.
Ahora no me digas
que todavía está frío
porque esto se está calentando.
¡Se está calentando!
Bueno,
coincido parcialmente
con Dani,
pero lo que yo cogería
de lo que dijo Kyle
fue básicamente
hablar mucho de empatía
al final también,
¿no?
De que teníamos que intentar
entender
los constraints
que tenían
los usuarios
en ese momento.
Si bien no tenemos
la capacidad
como empresas,
digamos,
o la empresa
donde trabajamos
no tiene la capacidad
de tener
los recursos
necesarios
para invertir
tiempo
y dinero
en esas
pequeñas cosas,
digámosle así,
podemos hacer
cosas pequeñas
como hacer
benchmarking
de voy a utilizar,
no sé,
date picker.
Entonces utilizo
el date picker
que utilice
el moment.js
o alguna alternativa
que sea más pequeña.
Que esas cosas
pequeñas también
al sumarse
ya tienen
un impacto,
¿no?
Entonces,
más que
en el ejemplo
que él daba
que decía,
bueno,
cuando estoy
en Estados Unidos
y tengo
mi red 4G
y tengo
una animación
súper pesada,
está bien
porque tengo
batería y todo,
pero si estoy
en Europa
con una
conexión
con 2G
que es gratuita
y tal,
entonces,
a ese punto
yo ya sentí
que se fue
muy lejos,
pero en esas
pequeñas cosas
que podemos
decidir día a día,
creo que
podemos.
Yo creo
que eso lo hacemos,
pero porque
forma parte
de ese tipo,
el ejemplo
concreto
de Moment
y DateFN
que serían
como las
EstadleteFN
que es la librería
pequeñita
y el Moment
que es la gigantesca,
yo creo que nosotros
siempre elegiríamos
DateFM
sobre Moment,
de hecho,
ahora no sé
si tenemos Moment
en producción,
creo que no,
¿no?
No,
no lo tenemos,
pero por temas
de performance
local
de nuestro,
de nuestra,
pero claro,
aquí lo que estamos
mirando son
nuestros usuarios,
miramos qué usuarios
tenemos nosotros
y vemos
que es una cosa
también que decía,
que dijo Kael Sinso
no hace falta
que miréis
Google Analytics
para saber
los usuarios
que tenéis
porque las estadísticas
es la muerte
de las personas,
ya,
pero es que
yo puedo estar
de acuerdo con esto,
que las estadísticas
es la muerte
de las personas,
pero también es verdad
que es muy difícil
llegar a obtener
información
si no aplicas
ciertos métodos
generales
de datos,
quiero decir,
cómo lo hacemos
si no,
porque yo puedo
tener una cierta área
de influencia
y yo puedo saber
más o menos
lo que funciona bien
en mi producto
porque mi pareja
es súper power user
de los productos
de Vinta
y más o menos
puedo tener
una idea intuitiva,
pero ya sé
que es muy frío,
pero al final
necesitas tener herramientas.
Es sesgado
al fin y al cabo,
si no lo miras
con datos
que es algo objetivo,
pues al final
estás tomando
opiniones sesgadas
y hubo alguien
que dijo,
no sé si fue
el propio Kael
o alguien
durante toda la conferencia
ponía el ejemplo
de que cuando
tomas opiniones
basadas en datos
estás excluyendo gente,
hay gente que se queda
fuera de la estadística
y puede ser verdad,
claro,
pero así funciona
la priorización
como tal,
es que...
Exacto,
pero ¿cómo priorizas?
Si no,
y estoy de acuerdo
que hay que hacer
un esfuerzo
en hacer las páginas
accesibles,
no estoy diciendo
nada de esto
que no tengas que invertir
en accesibilidad,
en performance,
etcétera,
etcétera,
pero con un poco de cabeza
y algunos de los ejemplos
de verdad me parecían desafortunados,
o sea,
poner el ejemplo
de la versión HTML
de Gmail
y decir,
si Google lo haces
¿por qué no haces tú?
Jolín,
es que el 95%
de las empresas
no tienen los recursos
que tiene Google
ni las necesidades,
claro.
Totalmente,
entonces,
vamos a matar este tema
porque yo creo que esto,
en realidad,
esto que estabas comentando
lo podría solucionar
un 10x Engineer.
Guau,
un 10x Engineer viene...
Porque tú tienes
un 10x Engineer
y esto que tú dices,
esto lo hace
y da igual que esté en Google,
que esté en Buddy,
que esté en Facebook,
que esté en King
o esté en Nespresso.
Con una mano
te lo hace en React
y con la otra en HTML.
Exacto,
te hace las dos versiones
a la vez.
Porque,
queridos oyentes
y los que nos estáis viendo
en YouTube en directo,
madre mía,
la que se ha liado
en Twitter esta semana
con el tema
de los 10x Engineers.
Entonces,
los que de alguna forma
no sé cómo
habéis esquivado la bala
y no os habéis enterado
de esto,
pues dejad que
os lo expliquemos.
El caso es que
el amigo de Carlos,
Shekar Kirani,
que digo que es tu amigo
porque sabéis
de dónde venía y todo.
Joder,
es de Axel,
así que tiene que ser.
Ahora,
que alguien me lo confirme,
porque si no voy a quedar fatal,
porque alguien me lo confirme.
Shekar,
creo que pensar
que es Shekar Kirani.
Si nos estáis escuchando,
pues nada,
escribe y nos confirmas
tu procedencia.
Empezó un hilo en Twitter
esta semana
que decía algo así.
Decía,
10x Engineers.
Dice,
Los fundadores se han dado cuenta
ya de que hay una extraña
raza de ingenieros
y tenéis que pillarlos.
Si has encontrado
un 10x Engineer,
los tienes que tener
en tu primer equipo
porque así
te va a aumentar
las posibilidades
de que tu startup
tenga éxito
significativamente.
Así que,
aquí está la pregunta difícil.
¿Cómo encuentras
un 10x Engineer?
Y aquí empieza el hilo
diciendo todos los pasos
o los 10 puntos
que tiene
un 10x Engineer.
Entonces,
si os parece,
yo voy a ir leyendo.
Dime, dime.
Fíjate en el detalle
que...
Me fijo.
¿A quién va dirigido
este hilo?
A los fundadores.
A fundadores.
Founders.
Fundadores.
Pensad en el prototipo
de persona
que funda una empresa.
Vale.
Alguien con pasta.
Dinero.
Seguramente,
con una buena idea,
con capital,
pero a lo mejor
no tiene mucha idea
de tecnología
y busca a alguien
que le programe
su productito.
Y su productito.
Y rápido.
Productito.
Rápido y barato.
Exacto.
Vale.
Muy bien.
El primer punto
y...
Bueno, mira.
Ana Amaro.
Vos días.
Vos días para ti también, Ana.
Bienvenida al programa
y no olvides de participar.
Y os invito a todos
los que nos estáis viendo
y estáis en YouTube
vamos aquí a ir leyendo.
Así que también participad
en cada punto
que lo iremos leyendo.
Punto 1.
Los 10x Engineers
odian las reuniones.
Piensan que son una pérdida
de tiempo
y que las cosas
que se están discutiendo
pues son obvias.
Ellos,
si atienden a las reuniones
es porque el manager
lo ha llamado
un staff meeting
para discutir
sobre características
y estatus.
Primera.
Jebser,
la primera,
¿qué te parece?
¿Empieza bien el 10x Engineer?
¿Va por la buena dirección?
Bueno,
yo creo que no tiene que ver
0x o 1x
o nx Engineer.
Creo que
cualquier persona
no va a querer
tener una mala reunión.
Entonces,
partimos del
de la base
que normalmente
hay varias reuniones
que
no tienen un gol,
no tienen,
o sea,
solo existen
para sentar gente
y hablar
de cosas.
Entonces,
creo que no es
de 10x,
simplemente que
la gente
no le gusta reuniones
cuando siente
que no
obtuvieron algo
de ellas.
O que no pueden
aportar.
O sea,
ya no obtener
sino aportar,
¿no?
Porque es,
yo creo que esto
es algo
mega común.
Yo no conozco a nadie
que diga,
a mí me encanta ir a reuniones
que no sirven para nada.
Yo sí,
mucha gente.
No,
¿en serio?
Hay gente que le encantan las reuniones.
¿En serio?
No me digáis que no.
Conocéis a nadie
que le encantan las reuniones.
Sí, sí, sí.
¿Sí?
Hombre,
a la mínima te hacen una reunión.
Totalmente.
Pero al menos es
porque obtienen ellos algo,
esa es una muy buena.
Estoy muy impopular.
Hoy estoy...
Hoy estás impopular,
¿eh?
Hoy estás impopular.
¿Y sabes?
¿Y puedes dar ejemplos con nombre?
No, es broma.
Es broma.
Sí que los tengo
pero no los voy a decir.
No,
pero sí que es verdad
que hay muchas reuniones
orientadas a proceso
y tal
que son muy improductivas
y las típicas reuniones
sin agenda
para solo para...
Voy a invitar a Carlos
aunque en realidad
quiero hablar con Miguel
solo por si digo algo
que a Carlos
le pueda interesar.
Este es el típico ejemplo.
O sea,
creo que es un problema
de no saber hacer reuniones
o no saber hacer reuniones productivas.
Y como dice Jebser,
este tipo de reuniones
no le gustan a nadie.
Ni a un UX engineer,
ni a un 10X,
ni a un 100X.
Hombre,
100X ya está en otra liga.
Bezabel Pérez dice
que está parcialmente de acuerdo
en el primer punto.
Yo también diría
que estoy parcialmente de acuerdo
porque obviamente
creo que ya cualquier ingeniero
es lo que decimos,
pero está bien
y esto puede servir de consejo
o es algo que yo he intentado
muchas veces
que no pasa nada
de salir
en mitad de una reunión
cuando uno se da cuenta
que es comida de gato.
Está la regla
de los dos pies,
¿no?
Si no te interesa
lo que se está hablando
en la reunión,
tienes dos pies,
los usas para irte
y ya está.
De hecho,
yo alguna vez
si he estado 10 minutos
sin hablar en una reunión
me levanto en medio.
Vale.
Sí, sí, sí.
Totalmente.
Y no pasa nada.
Y esto no creo que sea
tanto de 10X.
No creo...
Vamos a volver un poco
a la definición que él pone
porque su definición
va un poquito más allá.
Su definición es
odia las reuniones
por default.
¿Vale?
O sea,
no es...
No le gustan las reuniones
improductivas,
sino que dice
odia las reuniones.
Y no va.
Y no va.
Solo va si el manager
pone una reunión
obligatoria
para todo el equipo.
Eso es como decir
que odia la interacción humana,
básicamente.
Sí.
De hecho,
más adelante
veremos otro punto al respecto.
Dailos Rafael Díaz Lara,
que tiene el nombre
seguramente más largo,
ha dicho,
venga,
nuevo sinónimo
de realista
impopular.
Uy.
O sea,
que está de acuerdo contigo.
Muy bien.
Parece ser.
Muy bien.
Vamos con el segundo punto
a ver qué dice nuestro amigo.
Dice,
los tiempos en la oficina
que tiene este 10X Engineer
es bastante
irregular
porque tienden a trabajar
cuando hay muy poca gente
en la oficina.
Y entonces,
si hay mucha,
mucha gente,
por ejemplo,
en un all-hands meeting,
en una reunión
que va toda la empresa,
ellos se vuelven invisibles.
De hecho,
ellos normalmente,
ellos o ellas
normalmente,
son de estos programadores
que se quedan
hasta altas horas de la noche
y llegan tarde a la oficina.
O sea,
son murciélagos.
En Batman.
Sí.
Hemos encontrado
10X Engineer.
Pero este es otro ejemplo
de persona
que odia la interacción humana
o que va un poco a su bola.
Que se planta
a las 11
o a las 12
en la oficina,
que nadie le puede decir nada
porque, bueno,
tiene como unas
reglas especiales
que cuando hay una reunión
aprovecha para
una reunión de estas
de toda la empresa
o de todo el equipo
o lo que sea,
aprovecha para escaquearse
y ponerse a currar
en sus historias.
Yo esto lo he visto mucho.
Sí, yo esto también lo he visto.
En concreto,
lo de...
Lo de...
Me encanta,
Carlos.
Es que lo he dicho,
yo también lo he visto mucho.
Pero,
te has puesto la cara
del palo
soy yo.
¿Sabes?
¿Ha puesto la cara
de soy yo?
¿Sabes?
Pero es que
no lo habéis podido ver
ni siquiera en el directo
de YouTube.
Pero es que así ya está...
Yo también lo he visto mucho.
Esto es un poco
como los vídeos
de pantomima full.
Cuando no te hace gracia
es que te han clavado.
No pasa nada, ¿eh?
O sea,
por ejemplo,
yo voy a decirlo,
a mí en los All Hands
normalmente los sigo
en streaming
porque no me están...
No sé,
es que a mí ir ahí
con tanta gente
y luego te cuesta hasta salir.
Yo normalmente
lo veo por streaming
y sigo trabajando
en mis cosas.
Entonces,
no sé si...
Pero que no pasa nada.
Si se cumple algún punto,
no pasa nada, ¿eh, Carlos?
Algunos puntos...
Yo he hecho la...
¿Habéis hecho la encuesta?
Ah, no, no, no.
¿Qué es la encuesta?
Está la encuesta
de 10X Ingenier.
Ah, sí.
A mí me ha dado
6X Ingenier.
Bueno.
Bueno, no está mal, no está mal.
Sí, sí.
Y creo que algunos puntos
coincidían
y otros no.
Y en este punto
de los All Hands
pues sí que coincidía.
Pero lo que sí que quería decir
era que sí que había visto gente
que llega a las 11 de la mañana
porque se va a las 9 de la noche
de la oficina.
Y, de hecho,
yo he estado en la oficina
a las 11 de la noche
y gente estaba trabajando
todavía ahí.
Ostras.
¿Sabes?
O sea que de bajar a la planta
a recoger el ordenador
y tal porque ya eran como
11 menos cuarto
o algo así
que nos quedamos...
¿Te acuerdas cuando nos quedamos?
Sí, sí.
Después.
Sí, sí, sí.
En aquella noche romántica.
Exactamente.
En la JS.
Pues había gente currando todavía.
Sí, sí, sí.
Ostras.
¿Qué te pasa nada?
A ver.
¿Eso no formaría parte
de la flexibilidad horaria?
Yo creo que sí.
A lo mejor si dices tus horas
y estás cómodo
y lo puedes hacer para...
Claro.
No lo pondría como algo más.
O sea, siempre y cuando
no perjudiques al equipo
de ninguna manera
y tal,
yo creo que
igual que tiene que haber
flexibilidad horaria
para entrar
y irte temprano,
pues también
lo mismo para entrar
y salir tarde.
No lo veo como algo
malo.
Lo que sí que es malo
es que tú
cada día llegues a una hora
así un poco impredecible
y que no avises.
Y que afecta al equipo.
Y que haya la daily
y a veces estés
y no estés, ¿no?
Siempre y cuando
trabajas en equipo
no tiene por qué ser
un problema.
A mí lo más molesto
de la lista esta
es todo el tufo
de asocial
que destila.
Sí.
Bueno, pues vamos
a seguir con la lista.
Vamos a ver.
Punto 3.
10X Engineers,
o sea,
esta es una chorrada
con piano.
El fondo de pantalla
de su portátil,
el 10X Engineer,
siempre,
típicamente es negro.
Porque le encanta
siempre cambiar
las cosas que vienen
por defecto.
Las teclas
que tiene más gastadas
son IFX.
En cambio,
la de A, S, E,
que son típicas
de email,
de gente que envía emails,
pues las tiene nuevas.
Sí, tonterías.
Hay un argumento
más arbitrario que este.
O sea...
No sé,
yo me he cambiado
el color del fondo
de pantalla.
¿Jepsel lo tiene negro?
Yo no, no.
Ah, vale, vale.
Yo de hecho,
dejo todo igual.
Soy de los cocos.
Yo tengo un iPhone
porque tiene el mismo
fondo de pantalla
como traía.
Claro.
O sea que tú no eres 10X.
No, yo no soy 10X.
¿Entonces?
No, pero me causa
mucha gracia que,
no sé,
cuando leí esto
la primera vez,
me imaginé
él viendo los teclados
de cada uno
de sus ingenieros,
¿sabes?
Para ver cómo...
En la entrevista, ¿no?
¿Puedes traer tu portátil?
No es un Mac.
No sé, no sé.
Primero,
¿a qué teclas tienes?
Ah, A, S...
Ok.
Pero ¿quién tiene un tema
claro en el editor?
Bueno, hay gente,
¿por qué no?
Sí, la verdad es que yo,
normalmente,
mis compañeros y compañeras
siempre tienen temas
más oscuros.
Supongo que es...
Pero es un tema de vista.
Es un tema de la vista,
que cansa menos.
Es un tema de la vista,
cansa menos,
consume menos energía,
pero hay gente
que tiene temas, claro.
Iru Hernández dice,
me encanta lo del fondo negro,
XD,
me imagino que también
es porque lo debe tener
negro.
Supersonic Gabe
dice que Carlos
no representa a todos.
A todos no representa
porque no va a Lul Hans.
Entonces,
no os podéis representar.
Es broma.
Vamos con el siguiente punto
y es el 4.
Dice,
los 10X Engineers
se conocen
cada línea de código
que llega a producción.
Si un QA
dice,
oye,
hay algún tipo de problema,
él sabe precisamente
dónde está el problema
o bug
y lo arregla
en horas,
en lugar de tardar días.
Esto es un esmel
del típico
amo del calabozo.
Bueno,
hay una charla muy buena
en YouTube
de una Barcelona
sobre Craftsmanship
de Raúl Araya
que habla
de este perfil
de compañero
o compañera,
el amo del calabozo.
El amo del calabozo
me encanta.
Es la típica persona
que está en la empresa
desde el principio
de los tiempos
que se ha picado
el 80% del código
que ese 80% del código
es intocable
ya sea porque no es limpio,
porque está enrevesado,
porque no tiene test
o lo que sea
y se le conoce
de P a Pa.
Es una persona
que se hace imprescindible
no por su calidad
sino porque aglutina
todo el conocimiento
de la base de código
y está en todos los pollos.
Sí.
Están en todos los pollos
porque muchos
los causa esa persona
y por eso
los sabe arreglar.
Y por eso
los sabe arreglar.
Es el típico ejemplo
de una persona
que no comparte conocimiento,
no se sienta a programar
con los demás,
no lo aumentan,
ya sea con test
o con lo que sea.
Spoilers, spoilers.
Sí, sí.
Sí, verdad, verdad.
Jebser, ¿qué?
¿Tú qué opinas de este?
¿O tú te sabes
todas las líneas?
No, yo no sé las líneas.
Yo soy de los que
siempre digo
¿cómo es?
¿Quién hizo esto?
Yo soy el del blame,
¿sabes?
El clic del blame
porque no sé
qué pasó ahí.
El blame.
Siempre es la misma persona.
No, pero
bueno,
he visto código,
yo no he podido
nunca empezar
un proyecto nuevo.
¿Desde cero?
Desde cero.
O sea, que siempre había
alguien ahí detrás
que ya sabía todo.
Ya había hecho las líneas.
Sobre eso del blame,
hay una extensión
que a mí me encanta
de Visual Studio Code
que es
GitHub Code Lens.
Sí.
¿GitHub Code Lens?
Bueno, no sé.
Pero básicamente
te dice todas las líneas.
Cuando te pones
anticipando la línea
te dice
esta línea,
la última persona
tocó fue esta.
Y la verdad
que está bastante guay.
Yo aquí tengo
una opinión un poco
contraria.
Venga, dale, Carlos, vamos.
He visto el caso contrario
de gente que no conoce
sus líneas de código.
Ah, bueno.
Que hace copy-paste.
Sí.
Entonces,
claro, claro,
pero esto es importante
que cuando...
Es imposible
saberte todo el código
de la aplicación,
pero es importante
que conozcas el código
que tú has escrito.
Sí.
Y esto no es la realidad.
En plan,
¿por qué has hecho esto?
¿Por qué has hecho esto así?
O sea, copy-paste
por todos lados
un montón.
O sea,
ya no solo de Staroverflow
sino de compañeros
y demás.
Entonces,
yo aquí sí que rompería
una lanza
en favor de este tuit.
No del tuit
como está escrito,
pero sí que diría
que si escribes código,
aunque lo copies,
porque yo también copio
un montón,
pero tienes que tener
la responsabilidad personal
de esforzarte
hasta entenderlo
perfectamente
porque estás hoy.
Vale.
Aquí,
gente del chat,
dice Iru Hernández
que le ha encantado
lo del fondo negro.
Dice que tiene tema
claro en el ID
solo para presentaciones.
Y es la Israel Ramírez
que tiene un fondo amarillo
y eso le resta 1X.
Se ha puesto de moda,
¿eh?
El fondo amarillo.
El fondo amarillo
con las letras marrones.
Sí.
Sí, sí.
Se ha puesto de moda.
Interesante.
Iru tiene el fondo negro
pero con mi logo
en medio.
Rodriguito,
inflatevo en los cascos
con cancelación de ruido
en modo Zen
de Visual Studio Code.
Esto te está
sumando puntos.
Jordi,
esta es muy buena,
Jordi MNZ
que supongo que es Muñoz,
el guardián del monolito.
El guardián del monolito
es buena también.
Esta me encanta.
Además es que
se me está ocurriendo
un compañero
que es exactamente así.
Un abrazo.
Daniel López,
el 10X Engineer
que ya sabe
dónde está el bug
en producción
antes de que se lo diga
el CUA
y no lo ha arreglado
antes,
es un cabrón.
Pablo Fernández,
si ves un código tuyo
de hace 3 meses
y te preguntas
quién hizo eso,
¿qué X eres?
Yo supongo que eres...
No sé,
a mí es que a veces
me pasa
y pienso
wow,
esto hace 3 meses
lo hice así.
Pero eso es bueno.
Sí,
eso es bueno,
eso es bueno.
O sea,
yo creo que eso es
que has aprendido.
Pero si te preguntas
¿qué hace esto?
Y lo escribí yo.
Bueno,
eso...
Eso...
X 1,5.
Eso creo que nos lo va a responder
un punto que viene más adelante,
¿vale?
Por ahora vamos al 5
que dice
casi todos los 10X Engineers
son full stack engineers.
Para ellos el código
es código
y no le importan
si es frontend,
backend,
API,
base de datos,
serverless,
etc.
Raramente he visto
a esta gente
hacer trabajo de UI.
Bueno...
Trabajo de UI...
Un momento.
Trabajo de UI
es de 1X,
claramente,
no es de 10X.
Hay clases.
Hay clases,
¿no?
La gran brecha,
la gran brecha está aquí.
Yo debes reconocer
que yo he sido así.
Ay, ay, ay.
Sí, es verdad.
Yo he sido así.
Yo me ha costado
hacer trabajo de UI,
pero por desconocimiento,
no por no querer
o por no considerarlo importante.
Bueno,
pero esto pasa a todo el mundo,
¿no?
Claro.
Quiero decir,
a todo el mundo
nos cuesta cosas
por desconocimiento
que dicen,
mejor no toco.
Claro, claro.
Bueno,
pero una cosa es desconocimiento
y otra cosa es
querer ser desconocido.
En ese sentido,
¿no?
O sea,
no querer aprender.
Es diferente.
Ojo, ¿eh?
A ver,
si yo me he empezado
mi curso de Gris SS,
todo el mundo puede.
¿Has empezado
tu curso de Gris SS?
Lo terminé.
Ay, ay, ay.
No me pareció
un buen curso.
Ah, bueno.
O sea,
es culpa del curso.
O sea,
aprendí Gris SS,
pero no me parecía.
Estaba bien hecho.
Muy bien.
Entonces,
¿creéis que sí,
que así son los 10X engineers?
Es que, a ver,
no creo que ser full stack
te haga mejor ingeniero.
No.
¿No?
Te hace,
o sea,
diferente y punto,
¿no?
O sea...
No,
yo estoy 10X engineer
ya hacía tiempo
que lo había oído
y tengo una opinión
muy diferente.
Creo que todo esto
que hay en el tweet
son más prejuicios
y cosas irrelevantes
que otra cosa.
Como has dicho antes,
claro,
esto viene para fundadores,
¿no?
Entonces,
este punto
supongo que es súper interesante
para ellos
porque deben pensar,
bueno,
esto es una desarrolladora
o un desarrollador
o un perro desarrollador
o lo que sea
que me pueda hacer de todo.
Claro.
Me importa,
me da igual cómo lo haga,
pero que me lo saque todo,
¿no?
Y la UI,
bueno,
que utilice Bootstrap
y ya está,
si tampoco quiero que sea bonito.
El típico,
la típica hombre o mujer orquesta
y ya está.
Exacto,
¿no?
Que toco de todo.
Toca de todo
y no va nada bien.
Ya está.
Exacto,
entonces yo supongo
que van por ahí
los tiros
de este punto.
A mí,
mira,
la pregunta de Bezael,
Bezael Pérez,
ah,
Bezael,
¿existen?
Sí,
existen.
Me parece una pregunta
súper válida,
¿eh?
El tema de los full stack
es todo para podcast,
¿eh?
¿Existen los full stack?
¿Qué son los full stack?
Pero el full stack
es un sueño húmedo
de los...
Yo es que llevo unos cuantos años
ya programando
y yo vengo de una época
en la que el fronte
ni el backend
no existía.
Todos éramos programadores
y tampoco existía
el concepto de full stack,
webmaster.
Claro,
y luego hubo...
Éramos todos programadores
y llegó un momento
en el que la gente
se empezó a especializar
y había gente
que se empezaba
a llamar frontend,
gente que se empezaba
a llamar backend,
pero de toda la vida
hemos tocado
de todo,
base de datos,
servicios
y UI,
HTML y CSS
y JavaScript.
Eso ahora se conoce
como full stack
y hay mucha gente
que dice que no existe.
Bueno,
seguramente será
porque cada especialidad
se ha ido llenando
de conocimientos,
accesorios suficientes
como para...
como para...
ser muy difícil
dominarlo todo,
¿no?
Es muy difícil
que tú domines Kafka
y yo qué sé,
y CSS Grid
y NoSQL
en profundidad.
Ahí es donde viene
el problema, ¿no?
Yo creo que
un full stack
sí que existe como tal,
pero lo que no existe
seguramente
es como lo buscan
muchas empresas.
Claro.
Que buscan el full stack
que es que tiene que...
A saber,
AWS con React,
que sea muy bueno
con Node
o con PHP,
con .NET
o con Java
o que...
El hombre orquestra
de toda la vida,
básicamente.
Sí,
pero es que no buscan
que sea orquesta,
es que buscan
que sean buenos en todo
y que sean productivos
al instante.
Entonces,
yo creo que sí,
esos son los que
no existen tanto.
Tú puedes ser polivalente,
puedes adaptarte rápido
a cualquier escenario,
pero claro,
alguien que te optimice
una base de datos,
que se sepa
todos los índices,
eso ya es una especialidad
de BA
de toda la vida
que requiere años
de experiencia
y de haberte peleado
solo con performance
de base de datos.
A la pregunta
de Bezael
que decía
existen los full stack,
pues Dailos decía
son los padres.
Pues sí,
seguramente
nuestros padres
sean full stack
porque han hecho
de todo.
Vamos a ver,
siguiente punto.
El punto 6
dice que los 10X Engines
pueden convertir
un pensamiento
en código
y lo tienen
en su mente
y lo pueden escribir
de una forma iterativa
y super fashion.
Le dan una característica
del producto
y la pueden escribir
completa
en una o dos sentadas
en unas 4 o 6 horas
siempre con una bebida
cafeinada
y sin distracciones.
¡Wow!
¿Tú te ves aquí,
Jebser,
o qué?
¿Te ves como el café
en dos sentadas?
Me encanta la expresión
en dos sentadas.
¿Por qué lo he escuchado?
No sé.
¿Te ves aquí reflejado?
No tengo comentarios
en eso,
me parece...
Una sobrada
ya directamente,
¿no?
El detalle
de la bebida cafeína
es importante también.
Sí, ¿no?
Es más tópico
y revienta esto, ¿eh?
Sí, sí, sí.
Conozco gente
que no le gusta
ni la Coca-Cola
ni el café, ¿sabes?
Sí, sí, yo también
y es del...
No, no,
es que tengo que...
Tengo que ponerlo
el café
si no, no,
esto no va
sobre programadores.
Si no, son tres sentadas
ya no...
Exacto.
¿Tú esto has escuchado, Carlos?
Lo de...
Esto lo programo yo
en dos sentadas.
Esto lo he escuchado
alguna vez, ¿eh?
Esto lo he escuchado
yo, literal...
Y nuevamente es...
Acaba mal.
El principio del fin.
Esto en los 90
acaba mal.
Acaba muy mal.
Hay una cosa en la...
Es que de los tuits...
No sé, igual...
Hay una cosa interesante
en ese tuit
que es que...
O al menos
que yo quiero entender
de ese tuit
que es que hay una parte
de la programación
que se hace antes
de escribir código.
Sí.
Y creo que es una cosa
que no se aprecia
lo suficiente
y que se piensa
que programar
es sentarte
a escribir código
hasta que funcione.
Y creo que
nos iría mucho mejor
si dedicamos
90% del tiempo
a pensar
y 10% del tiempo
a programar.
Sí.
Pero es que según este hombre
ya lo tienes en tu cabeza.
No todo tienes que pensar.
Ya lo tienes.
Sí, bueno.
Hago la interpretación
para meter mi libro.
Es Minority Report ya.
Si me voy a contar mi libro
intento sacar un poco oro.
Fui a por...
¿Sabes?
Pero bueno,
que me parece interesante
estas cosas.
Punto 7.
Los 10X Engineers
muy pocas veces
esto me parece increíble
raramente
buscan ayuda
en la documentación
de las clases
o los métodos.
Ellos se lo saben
de memoria
y lo pueden recordar
de memoria.
Entonces ellos
escriben
el código tan fácil
como escriben inglés
sin pausa
sin vamos
sin parar
solo picando código
y que sí.
Madre mía.
Bueno.
Tú imagínate
que estás...
O sea,
¿cómo no miras documentación?
Porque quiero decir,
en algún momento
tienes que mirar documentación.
Es imposible que sepas
de memoria
lo que no sabes.
Yo llevo 13 años
y todavía no sé
si es Split o Splice
que hace uno
que hace el otro.
Ya,
a mí también me cuesta eso.
Es que...
Lo que no sabes
todo de memoria.
La API de MDN
es entera.
De hecho,
la ha escrito él.
Ah, no.
No la ha escrito él
porque más adelante
dice algo sobre esto.
No escriben documentación.
No escriben documentación.
Entonces,
¿qué?
Un 10X Engineer...
Yo tengo que reconocer
que si hay una persona
que es capaz de programar
todos sus días
de su vida
sin mirar documentación,
yo le concedo
el título de 10X.
Yo se lo doy.
Pero en algún momento
lo he tenido que mirar.
No,
pero si no lo mira
y de verdad lo programa,
yo se lo doy.
Aunque sea al principio,
el primer día de trabajo
se la ha tenido que mirar.
Lo sé.
O ya lo sabe.
Ya vienen los genes.
Lea el código,
lee el código.
Él aclarele el código.
Puede ser igual
tan friki
que entra a la definición
del código fuente.
Le da el punto.
Exacto.
Le da el punto
y ya con el IntelliSense
ya se apaña.
Se lo lee.
No,
pero él va directamente
al código fuente.
Ni siquiera se fía a IntelliSense.
Él va al no de modus.
No sinceros.
Vale.
Punto 8.
¿Cómo vamos de puntuaciones
por ahora?
¿Estamos de acuerdo?
¿Poco de acuerdo?
¿Muy de acuerdo?
¿Nada de acuerdo?
¿Cómo va la cosa?
Creo que no estamos muy de acuerdo.
Insisto,
yo creo que la mayoría
de los argumentos
están basados en prejuicios.
Vale.
Vamos aquí
con el punto 8.
Los 10X Engineers
siempre están aprendiendo
nuevos frameworks,
lenguajes
y siempre están por delante
de cualquiera
en la compañía.
Ellos no están preocupados
de nada nuevo.
Y si hay algo nuevo,
como por ejemplo
el blockchain,
pues venga,
se lo instalan,
se ponen a experimentar
y lo entienden antes
de que nadie empiece.
Vamos,
que casi que lo ha inventado él.
Casi que lo ha inventado
él mismo.
No sé,
esto tiene pinta
de ser alguien inquieto,
¿no?
Y ya está.
Bueno,
puede ser inquieto,
pero seguramente
es una persona
que no está centrada
en los problemas
que tienen sus compañeros
y está mirando
pues la siguiente librería,
la siguiente tendencia
en Twitter
o donde sea.
¿Entonces tiene Twitter
un 10xEngineer?
¿Creemos que tiene Twitter?
Podría,
podría,
¿no?
No lo sé.
Pero por consola.
Ah,
exacto.
¿Por la terminal?
Por la terminal.
No lo sé
si tendría Twitter
o no,
no lo sé.
Pero sí que
seguramente
pues está,
acaba de salir
el nuevo framework,
no,
el nuevo framework,
la nueva
característica
de JavaScript
que está en fase
cero,
stage cero,
pues venga,
ya la empiezo a usar.
En producción.
Venga,
en producción,
venga,
para adelante,
ya está.
Claro,
yo creo que ese es el problema.
No es tanto,
me parece guay
que haya gente
que se tire,
que se mire
los de estos.
Claro.
El problema es cuando se hace
hype driving development.
Sí.
Que puede conllevar
un poco a acabar
haciendo hype driving development.
Y,
venga,
todo para dentro.
Que hace dos meses
has tomado una decisión
de empezar a implementar
lo que sea
y antes de acabar
todo el rollout
ya estás mirando la siguiente.
Sí.
Venga,
hay que cambiarlo todo
porque he descubierto esto.
Sí.
Cuidado con eso.
Es que luego lo hablamos,
pero parece que los 10x engineers
son esa persona o figura
que vas muy rápido al principio
pero que luego...
Exacto.
Cuídate las espaldas
que esto se paga.
Es un poco...
Esto se paga.
Creador de deuda técnica.
Sí, ¿no?
Y por eso él sabe
dónde están todos los problemas
porque es el que ha creado
toda esa deuda.
Porque yo no veo
en ninguno de estos puntos
nada que hable
de escribir código mantenible,
de escribir test,
de compartir conocimiento
con compañeros,
de documentar...
Pero sí que habla de eso.
¿Ah, sí?
Sí.
Lo tienes aquí
en el siguiente punto.
Dime, dime.
En el punto nueve.
10x engineers son mentores,
son muy malos mentores
ya que no pueden enseñar a nadie.
No pueden enseñar a nadie
ni cómo se hacen
ni cómo funcionan las cosas
porque ellos siempre piensan
uff, enseñar pues cuesta demasiado
y discutir con los demás
esto es una pérdida de tiempo.
Mejor lo hago yo mismo.
Así que también
hacen muy mal las entrevistas.
Es que esto me parece
lo más grave de todo el hilo.
Oh.
Sinceramente.
Claro, porque...
Uy, me lo vienen a visitar.
Realmente lo que más valoro yo
en alguien a quien poder considerar
10x engineer
es alguien que haga
que toda la gente que le rodea
rinda por encima de su capacidad.
Y para mí eso es un gran mentor.
Y su principal habilidad
es ser un buen mentor,
alguien que se sienta
a trabajar con los demás,
alguien que no es que se sepa
todas las líneas del código
sino que habilita
y hace de facilitador
para todo el resto del equipo.
Alguien así sí que es imprescindible.
Justamente alguien que multiplica.
Exacto.
Alguien que multiplica
pero que multiplica a los demás.
Exacto.
No lo que hace el mismo.
Exacto.
Sí, es que si al final
él mismo se multiplica por 10
pero deja de multiplicar a los demás
pues a lo mejor es mucho peor.
Claro.
Si multiplicas a 5 personas por 5
pues entonces ya son más.
Es que una persona así
dentro de un equipo
lo dinamita
porque nadie se atreve a tocar nada
que haya sido codificado
por esta persona.
Y lo peor
es que eres rehén de esa persona.
Tu empresa
es rehén de esa persona
porque si el día de mañana
dice me voy
entonces
Tiembla.
Ojo cuidado
¿cómo se llamaba el estumbre?
Ojo cuidado
checar Kirani
que te vas a quedar Kirani
pero Kirani.
Este founder
que contrata
a una persona
de este estilo
seguramente tiene
su primer MVP
muy rápido
y es
el típico prototipo
que acaba en producción
y que empieza a escalar.
Entonces la empresa empieza a escalar
contratas más gente
y ese código
que se ha escrito
rápido
por una máquina
de estos
pues acaba siendo inmantenible
y es lo que tú dices
acaba siendo rehén
de esta persona.
Es el que se picó
aquella pieza de funcionalidad
que además es clave
para el negocio
y que nadie se atreve a tocar.
Y nadie la entiende
porque no se la quiso enseñar
porque ha tardado mucho tiempo
en enseñarlo.
Es que es imposible
hacer un proyecto
que merezca la pena
un tío solo.
O sea por muy 10x
por muy 10x que sea
no sé si es un proyecto
que merezca la pena
es imposible.
Es un tío solo.
Así que si no sabes
trabajar en equipo
está complicado.
Pero todo lo que ha dicho
son ingredientes
para un silo.
Claro.
Es simplemente
el amo del monolito.
Es el amo del monolito.
Sí, los de conocimientos
y es que esto está
estudiadísimo.
¿Has conocido a alguien así
Jebsen en tu vida?
Bueno, 10x como tal.
Bueno, 10x
que tenga
este punto de que
digo 10x
es de este punto
que diga
no, yo es que
paso de enseñarle
a la gente
que tardo mucho.
Yo entiendo
un punto
de que pueden haber
personas que
más que no les gusta
enseñar
o quieran quedarse
con el conocimiento.
Es parte de esto
de tener
problemas
de comunicación
o interacción
con personas
que prefieren
no hacerlos
porque les cuesta
explicar, exponer
de una forma sencilla
y lo veo desde la uni
o sea, con profesores
también, ¿sabes?
Claro.
Profesores que te explicaban
cosas y tú te quedabas
igual porque era
tan alto el nivel
que no podían, digamos,
bajar.
Eso es verdad
y es muy interesante
y es que muchas veces
en este hilo justamente
hablamos de que
tiene que ser 10x
en codificar y tal
pero no hablamos
de cómo tiene que ser
en otro tipo de actitudes, ¿no?
O sea, que tiene que ser
por ejemplo, pues
explicando al compañero
haciendo una presentación
o todo esto.
Pues ya tenemos la última
el último punto
que es 10x Engineer
es raramente
se pone a buscar
un trabajo
o se cambia de compañía
porque si ellos
se cambian de compañía
es porque su vida
es miserable
es porque están haciendo
su vida miserable
con el proceso
con las reuniones
con los entrenamientos
o con cosas que no
le están añadiendo valor
así que si te cruzas
con ellos
ya sabes
te los quedas
y los celebras
y les subes el sueldo
y les haces una estatua
y vamos
le pones un pin
Bueno, no sé
también me parece muy irrelevante
¿no?
que no se cambie de empleo
o sea
a lo mejor no te cambias de empleo
porque estás a gusto
y ya está
o porque cobras un buen sueldo
o porque
te sientes realizado
en el trabajo
en el que estás
no sé
lo veo muy irrelevante
todo
Sí, pero viendo la definición
que hace
del tipo
los tuits anteriores
claro, no se cambia de empleo
porque según los tuits anteriores
lo que tiene ahí
es su cortijo montado
Claro
Yo tengo mi cortijo
que nadie me tose
¿por qué me voy a cambiar?
Nadie me tose
tengo al manager
haciéndome la pelota
por no decir otra cosa
seguramente
a la que amenaza con irse
le suben el sueldo
para que no se vaya
Claro
Claro
tiene a la empresa de REN
Pues hablando de irse
se nos tiene que ir
de Daniel
de la Cruz
y bueno
entonces no es 10x
porque te vas
me tengo que
me tengo que
te marchas
te marchas un poquito tarde
pero bueno
podéis seguir
No, hombre
por supuesto
ahora vamos a terminar
pero antes
pues nada
muchas gracias por venir
Dani
ha sido un verdadero placer
Gracias a vosotros
Gracias
nos hemos dado cuenta
que no es 10x
eres vamos
yo no
asterisco x
yo soy un mindundi
asterisco x
decía por aquí
Dalios
un poco de lo que tú decías Dani
que a lo mejor
la palabra
ya no es multiplicar
sino potenciar
y por lo tanto
con todas las opiniones
dadas en este podcast
estaríamos definiendo
a un x elevado
a 10 engineer
Claro
alguien que potencia
alguien que habilita
a los demás
alguien que
básicamente
hace que los demás
sean mejores
acelerar
exacto
totalmente
y de formas
que no tienen nada
que ver con el código
además
a lo mejor
pues de prácticas
de procesos
de
soft skills
de lo que sea
Muy bien
bueno Dani
pues muchísimas gracias
por estar aquí
vamos a hacer una pequeña pausa
mientras se va Dani
y te esperamos ver muy prontito
muy bien
hasta la otra
Tau t
Gracias por ver el video.
Gracias por ver el video.
Gracias por ver el video.
Gracias por ver el video.
Gracias por ver el video.
Gracias por ver el video.
Gracias.
Gracias por ver el video.
Gracias.
Gracias.
Gracias.


Bueno, esos son otros temas, ¿no?
Pero era un poco esto, ¿no?
Jebser, cuenta, cuenta.
Te da vergüenza, ¿eh?
De falar, no, yo no he dicho nada de esto.
Yo no he dicho esto.
No, yo le comentaba a Miguel que...
Él habla desde su perspectiva, ¿no?
Él claramente no tiene el conocimiento, la perspectiva desde nuestro punto de vista y por eso se creó este revuelo de comentarios.
Exacto.
Él lo ve desde una perspectiva, desde un punto que quizás no sabe ni de lo que habla, básicamente.
Pero claro, es verdad que ha faltado un puntito de empatía. Yo no estoy de acuerdo con esta persona, por supuesto. Ya hemos visto que los puntos no tienen mucho sentido. Pero teniendo en cuenta que no tiene ni idea de lo que habla y desde su punto en otra, no sé, desde otro edificio, digamos, que está mirando. Claro, es lo que él desearía o su sueño, ¿no? Lo que le encantaría que ocurriese, ¿no? Que existiese esta figura que te lo soluciona todo.
Maravilloso.
Y ya está. Súper fácil.
Sería maravilloso. Pago una persona y me resuelve todos los problemas de desarrollo de la empresa.
Exacto.
Sería maravilloso.
Y súper barato y súper bien y... No sé, es un poco complicado. Pues no sé, ¿queréis decir algunas últimas palabras? Mira, decía Rodriguito, ¿quién es el autor del tuit? El autor del tuit, no sé si voy a ser capaz de encontrarlo ahora. ¿Lo tienes por ahí, Carlos?
No, no lo tengo.
Ay, pues mira, justo lo tenía, pero como ya... Mira, te lo busco, lo tengo en elementos guardados. Shekar Kirani, 10x Engineer. Shekar Kirani. Tiene 31.000 seguidores. Hombre, 31.000 seguidores, la verdad. Es de India.
Sí, sí. No, no, si Axel es una consultora India.
No, pero él pone que está en India. 31.000 seguidores, hombre, es un... Es bastante tocho.
Luego, ha vuelto a escribir sobre esto, ¿eh? Que estaba bastante sorprendido sobre los puntos de vista extremos del 10x Engineer, que bueno, ¿qué pasa?
Que son contribuidores bastante individuales, que es verdad que no trabajan bien en equipo.
¿Y qué? Sí, también pueden ser... Estos pueden ser fenomenales en fases del producto que están empezando.
Claro, es que... Esto yo creo que es lo que quiere, ¿no? Una persona que se lo haga todo al principio y ya está.
Como dice el dicho, el que mucha barca, poco aprieta, con ser 1x Engineer nos basta y de sobra.
¿Estamos ahí?
Yo creo que si cogemos la parte esta de 10x, habíamos dicho que es una persona que multiplica, ¿no?
O sea, no sobre esos términos que están en el tuit, pero por otros.
Exacto.
Entonces, para mí, en vez de ser criticando el punto de... Bueno, está bien que critiquemos porque no estamos de acuerdo,
pero creo que también si lo movemos para la aguja, a otro lado, y decimos, bueno, que es un 10x Engineer para nosotros...
Exacto.
Podría ser una persona que trabaja en equipo, que entiende los constraints, quizás no se sabe todas las líneas de código,
pero sabe cómo resolver problemas, es un buen comunicador o al menos hace el intento.
Exacto.
Alguien que suma, básicamente.
De hecho, es muy fuerte porque han hecho una página web de 1x.engineer que habla un poquito de todos los puntos que tendría un 1x.
Tiene un montón de puntos, pero vamos a hacer el juego, si os parece, y hacerlo muy rápido, ¿vale?
Y comentamos, lo leo, y decimos, los tres decimos sí, sí o no, o no, no, sí, ¿vale?
Y que cada uno diga sí o no, ¿vale?
Rápidamente.
Y vosotros, pues, oyentes, lo hacéis desde vuestras casas.
Si estáis en el coche, mucha gente, sabemos que nos escucha en el coche,
pues mirad a la carretera, pero también hacete ejercicio.
1x.engineer busca en Google cuando no está seguro de lo que está haciendo.
Sí.
¿Sí?
Sí.
Yo he sentido que sigo la cabeza, pero que no me escuchen en Buddy, a ver si.
Dedica tiempo fuera de cosas que son ingeniería, como puede ser hobbies, amigos y familia.
¿Sí?
Sí.
Esto va a ser bastante fácil, ¿eh?
Escribe el código con errores.
Obvio, ¿no?
Es que, a ver, escribir código y errores, bugs, es como, escribe código que los otros pueden leer.
A veces.
Sí.
A veces.
Si te lo haces lo posible.
Intento que sí, pero a veces.
Es un jugador de equipo y va a todos los meetings con sus co-workers siempre que está requerido.
Sí, sí, está requerido.
¿Se lee la documentación?
No siempre.
Yo soy un aboque de hacer y leer la documentación.
Y sí, me pongo un poco así molesto cuando me hacen preguntas, es como, ¿tienes el ritmo?
Le he tenido la documentación.
Exacto.
Yo tengo la...
Ay, yo no voy a ser molestos.
¿Hace pushes a producción los viernes?
Sí.
Yo sí.
Y soy bastante nazi con esto.
Yo digo que sí que hay que hacerlo.
A mí me da igual.
O sea, si tienes un pipeline decente para lanzar features, no veo por qué no.
Exacto.
Dicen, ¿no es apasionado sobre el código que escribe o los problemas que soluciona?
Pero quizás sí.
Hombre, sí, ¿no?
¿Siempre está deseando colaborar con los demás?
A veces.
A veces.
Yo reconozco que a veces.
A veces estoy en mi pequeña burbuja enfocado en un problema y me cuesta.
Claro, depende si estás hiper concentrado en lo tuyo y tal.
Pues obviamente en ese momento.
Y hace copy-paste de snippets de código de Stack Overflow.
Ojo, cuidado.
Totalmente.
Anda que no he hecho yo copy-paste.
Yo he hecho copy-paste, pero intentad entenderlo antes.
Que si no, luego trabaja para vivir y no vive para trabajar.
Esa sería la más importante.
Sí, ¿no?
Sí.
Muy bien, chicos.
Pues esto ha sido el 10xEngineers.
Espero que os haya gustado nuestras opiniones y las de la gente que estaba en el chat.
Dice Dailos que no se hace pushes a pro un viernes.
Por Dios.
Pues yo la verdad es que considero que eso suele ser un smell.
Yo cuando llegué a mi empresa me decían que los viernes estaba prohibido hacer pases a producción.
Luego resulta que los jueves por la tarde también estaba prohibido porque estaba cerca del viernes.
Luego resulta que jueves por la mañana también era mala fecha porque estaba cerca del jueves por la tarde.
Y también entonces el miércoles, nada, que había que ser el lunes.
Y yo decía...
Lo que pasa es que mucho escenario depende de ti.
Quiero decir, tú puedes estar decidido a hacerlo, pero si hay un problema y tal, igual tienes un marronazo tú solo.
Sí.
Tienes que tener el equipo trabajando de la misma forma.
Claro.
Pero per se, pensar...
Los viernes nos hace un paso a producción.
Yo lo entiendo bien.
Es que eso depende al final, ¿no?
Porque, por ejemplo, en Buddy de momento estamos tratando de mejorar el pipeline de Deployts.
Y si existe la ceremonia de release por cuestiones de ahora que está en la empresa o cuestiones de producto, etcétera, etcétera.
Pero yo creo que sería que pudieras hacer Deployts a producción y no daría ningún problema.
Porque si tienes test in play, o sea, unit test, integration test, no.
O sea, el Surface es mucho más pequeño, entonces...
Exacto.
De reloj.
Claro.
Totalmente.
Los fines de semana son para investigar cosas nuevas, dice Dailos.
Y para descansar también.
Para descansar.
Y para tocar la guitarra o para grabar un podcast de What the Front.
Así que, bueno, nos vamos a ir despidiendo.
Vamos a ir despidiendo.
Pero una vez que la escuchas, ya se te queda adentro.
Es cachín, ¿no?
Sí.
Está guay, está guay.
Luego vas a volver a casa ahí.
Como caminando en un pequeño Pokémon.
Bueno, Jebser, muchas gracias por estrenarte aquí en What the Front.
¿Cómo te has sentido, aunque has llegado tarde?
¿Cómo estás?
Muy bien, la verdad es que está interesante.
Gracias por invitarme.
Nada, gracias a ti por venir.
Espero que vuelvas la próxima vez que vuelvas en hora.
Hemos dicho que tú eras de esta gente que se toma un 10x de tiempo.
Bueno, vivo en Barcelona, centro y me quedo un poco lejos.
Para la próxima.
Me levanto más temprano.
Eso suele ayudar a llegar bien a los sitios.
Lo sé por experiencia.
Cuando no me levanto temprano, pues llego tarde.
No sé por qué.
Es una cosa.
Bueno, Carlos, pues una vez más aquí.
¿Otra vez?
¿Qué te parece?
¿Cómo te quedas?
Pues me quedo 10x patidifuso.
Patidifuso.
Sí, sí, sí.
Pues nada, muchas gracias, Dani.
Dani.
Ay, es verdad, si lo hemos despedido antes.
Muchas gracias a todos.
Había habido hasta 30 espectadores simultáneos en YouTube.
Os recuerdo a todos los oyentes que normalmente los grabamos y estamos aquí en vivo para leer
todo lo que decís.
Ha habido un montón de gente que está diciendo cosas muy guays como Dailos, Rodriguito, Sergio
Peña, Iza, Besael, Manu Mora, Supersonic.
Voy a ver si no repito a nadie.
Pablo Fernández, lo he dicho ya.
Jordi Muñoz, Daniel López, Israel Ramírez.
Bueno, ha habido un montón de gente.
Muchas gracias a todos los que os habéis apuntado un ratito.
José Lorenzo.
Esto es What the Front.
Nos podéis escuchar en Spotify, en iVoox.
También estamos en Google Podcast.
Luego también tenemos nuestra web, que es wtf.fm.
Creo que es el dominio más chulo y más desaprovechado del mundo.
Porque entras y solo hay tres podcasts, como que solo hemos hecho tres.
Nunca lo volvemos a actualizar.
Pero bueno, espero que este verano tengamos la ocasión de actualizarlo.
Y nada, Jebser, ¿dónde te pueden encontrar para que la gente sepa de ti?
Jebser Bernardino de Badí.
Mejor si no.
¿Cómo?
Mejor si no saben de mí.
Mejor si no saben de Jebser.
Muy bien, perfecto.
Nada, no es cierto.
Bueno, me at Jebser, básicamente en Twitter.
No te he posteado mucho, pero me gusta escribir artículos.
Entonces pueden encontrar un par de artículos técnicos hablando de JavaScript en general.
Un par de charlas por ahí.
Muy bien.
Es un chico muy interesante, no solo en temas de programación.
A mí me ha explicado cosas muy, muy, muy interesantes de otras cosas que no puedo explicar aquí.
Porque bueno, son muy...
Ay, broma.
Te voy a poner una cara así de...
No, Jebser, la verdad es que tienes un nick bastante guay.
No como mucha gente que tiene D, 4, V, I, latina, D, mayúscula...
Que parece el password.
Sí, parece el password.
Sí, sí, sí.
Y dices, bueno, pues igual cámbiatelo.
¿Dónde te pueden encontrar a ti, Carlos?
Pues como siempre estoy en Twitter, Carlos Villu.
Y también...
Con V.
Con V.
Y también en el canal de YouTube, que la verdad es que hace tiempo que no subo nada.
Que es también con V.
Que es también con V.
Y Carlos Villu.
Carlos, la A es con A, no es con 4.
La A es con A, la C es con C y la R es con R.
Perfecto, o sea, Carlos ha tenido suerte.
Muy bien, pues al final, Sergio Peña ya me está preguntando.
¿De quién es la sintonía del final?
Sí que es pegadiza.
No lo puedo decir.
Me dijeron que no dijese.
Dani Paredes nos dice que hasta la próxima.
Muchas gracias a todos por escucharnos.
Esto ha sido What the Front.
A mí me podéis encontrar en arroba midudev en Twitter.
Y como midudev me podéis encontrar en casi todos los sitios.
Me podéis encontrar en Facebook, en YouTube.
Me podéis encontrar en LinkedIn.
Me podéis encontrar también, creo que podéis abrir la nevera.
Y en el tercer cajón ahí estoy, como midudev.
Mírate antes la fecha de caducidad, no vaya a ser que esté caducado.
Muchas gracias a todos por escucharnos y nos escuchamos en el siguiente.
Ya sabéis, no dejéis nunca, nunca, nunca de darle al frontend.
¡Hasta luego!