Mis libros favoritos

Muchos libros pasan por una vida pero muy pocos se quedan. No tenía una lista y para ser un personaje notable hay que tener una, así que ahí va, estos son los que me han marcado de una u otra forma:

Los cómics de “Asterix y Obelix” Uderzo & Goscinny . Me encantaba la historia de unos señores muy raros ganando a los grandes con su fórmula mágica, sin mucha organización, sin teatro, sin ser muy sofisticados. Me quedaba siempre impresionado como con dos trazos eran capaces de definir un movimiento y una expresión. Durante una época quise ser dibujante de comics, gané un premio pero luego me di cuenta que no era lo mio.

“El universo” de Isaac Asimov: lo leí cuando tenía 16 años o algo así. Era un libro de bolsillo que tenía las páginas ya amarillas en los bordes. Lo empecé a leer buscando respuestas, tuve una crisis importante al darme cuenta de que no podía explicar en qué lugar estaban los humanos, no podía entender (y sigo sin hacerlo) que el universo sea “infinito”. Me quedé alucinado con las explicaciones de cómo hace ya unos miles de años eran capaces de medir distancias interplanetarias con palos, matemáticas básicas y mucha inteligencia (los fundamentos siempre son un buen fondo de armario) No encontré la respuesta a lo que buscaba.

“Historia del tiempo” de Hawking: lo leí después del de Asimov me reventó mi adolescencia con el tema de la demostración que hace de que Dios no puede existir. Tampoco encontré la respuesta.

“The pragmatic programmer” David Thomas & Andrew Hunt: es de los mejores libros de programación nunca escritos, atemporal, buenos consejos, al grano. Cuando lo lei consiguió dar sentido a muchas de las cosas que instintivamente creía.

“The ghost in the wires” de Kevin mitnik: el libro no dejan de ser anécdotas pero me marcó el hecho de ver que ilusos y controlables somos los humanos.

“Grushenka· (Anónimo): un libro erótico que vaya usted a saber cómo cayó en mis manos pero era, desde luego, menor de edad. No se si lo leí demasiado pronto o demasiado tarde. No recuerdo tampoco si era un buen libro o no, pero me dejó especialmente marcado. Debe ser como un chaval de 13 años que encuentra PornHub (aunque seguramente el libro es un poco más real) por casualidad.

“How to build a car”, Adrian Newey: me encanta la tecnología llevada al extremo y en cierto modo me recuerda a mi carrera profesional (salvando las distancias, tristemente). No deja de ser una biografía que si no te gusta la F1 seguramente pierda el 90% del encanto, pero puede ser interesante aunque no la sigas.

“Visual display of quantitative information”, Tufte: si escribo un libro sobre datos (y no lo descarto) me gustaría que fuese así. Es un libro de teoría y fundamentos, bien escrito, buenos ejemplos y encima en con edición física brutal. Bueno, quizá mi libro sería una mezcla entre este y “The laws of simplicity” the Maeda.

“Getting real”, DHH & Jason Fried: me lo leí cuando estaba en pleno apogeo con Agroguia (una empresa que fundé hace 18 años) y que resonaba cada párrafo que leía. Un poco desactualizado pero el mejor libro si estás haciendo el 0 a 1 de una empresa. Aviso: soy muy fan de 37signals y eso puede que este libro tenga una evaluación un tanto inflada

“Creativity inc” Amy Wallace and Edwin Catmull: es el mejor libro de gestión empresarial nunca escrito y de paso te cuenta una historia increíble. Me ha marcado especialmente porque Toy Story tuvo un impacto grande, pensar en cómo era posible hacer algo en 3d con un PC era magia (aún no sabía nada de programación en aquella época). Leer la historia lo hace más épico si cabe. La frase del libro:

Getting the team right is the necessary precursor to getting the ideas right. It is easy to say you want talented people, and you do, but the way those people interact with one another is the real key. Even the smartest people can form an ineffective team if they are mismatched.

“The baby owners manual”, Louis Borgenicht M.D, Joe Borgenicht : ayudó a calmar la ansiedad de tener un ser a tu cargo los primeros días de su vida y hay pocas que ayuden más en ese momento. La mejor parte es que te enseñan cómo hacer un burrito con tu bebé, mano de santo.

Seguramente haya más, algunos libros del instituto los recuerdo con especial cariño, algunos que te han regalado, otros que nunca terminaste porque te daban vergüenza ajena (como 4-hour-work-week), los que te compraste pero que nunca vas a leer o los que te gustaría que te gustasen (como la novela o los clásicos en mi caso)

Recortes del 2023

Algunos recortes del año, dicho de otra forma, las cosas que he leído que tras 12 meses siguen resonando en mi cabeza, sin orden alguno, con una mezcla entre lo personal y lo profesional, con sus respectivos comentarios.

· fuente. Serán los últimos coletazos de la crisis de los 40, será que estoy cambiando, pero este tipo de contenido me resuenta más. Será momento de retomar a Coelho?

· High variance management - define claramente que hay dos tipos de situaciones que gestionar, las de velocidad de crucero o en las que tienes que ir a la selva, rescatar a los rehenes y salir de allí sin conocer el terreno. Creo que define bien mi estilo de gestión (por decir algo), de muy alta varianza, o mejor dicho, en la línea del desastre.

· Jean-Michel Lemieux (ex CTO shopify y otras muchas cosas interesantes) escribe

hey managers, going into the weeds is not the problem staying in the weeds is the problem never going into the weeds is fatal

Exactamente eso, mucha gente se empeña en llamar micromanagement a la forma de defender cierta incompetencia. No conozco a nadie competente que no te mande a la mierda si te metes donde no te llamen o que no esté dispuesto a hacer lo que le salga de las narices si cree que es lo correcto.

· Understanding DeepMind’s Sorting Algorithm - Justine Tunney es de las figuras, creo, más relevantes en aproximar el software de una forma diferente. Tuvo que venir a explicar como lo que DeepMind no hizo.

· Esta delicia de artículo donde Signal (la app de comunicación segura) hace un análisis de costes a nivel de ingeniería que debería ser obligatorio en todas las empresas

· Esta historia sobre el niño que mandó una carta a Francisco Ibañez pidiéndole consejo para ser dibujante de tebeos. Qué maravilla, cada párrafo, aunque explicando cosas muy concretas, es una lección [de vida]. Pego la imagen por si se pierde el tuit. Seguramente me llega al corazón especialmente porque pasé mi infancia entre Asterix y Mortadelo, solo pueda dar las gracias a la fantástica biblioteca pública que tenía mi pueblo.

· El CEO de snowflake es un lebrel de cuidado, por ejemplo con esto argumetando que los CEOs (y creo que cualquier puesto de gestión) no puede no estar empujando. Este podcast tambien es MUY bueno.

· Startup Restructuring 101. Es un artículo que como fundador te pone en tu sitio. Este año, cuando Silicon Valley Bank se fue a tomar por culo, nosotros teníamos “solo” un par de kilos allí, aunque gran parte del resto estaba en otro banco que iba a ser uno de los siguientes en caer si nadie arreglaba aquello. Recuerdo el sábado por la tarde como abrimos una excel y empezamos a ver como podríamos hacer sobrevivir la empresa con solo el dinero que sabíamos “seguro” no íbamos a ver esfumar. Un ejercicio brutal. Por otro lado, me encanta el término “mokita”, lo uso a menudo.

The truth we all know but agree not to talk about - Mokita, in New Guinean

· Una de las mejores formas de negociar es “decir la verdad” (fuente) Especialmente personas no especialmente espabiladas (como un servidor) a veces ir de frente es la mejor estrategia.

· Hacer cosas inútiles no es tan inútil como parece. Soy un gran aficionado a buscar “aire” para hacer cosas a priori poco útiles.

· Esta entrevista al CEO de teenage.engineering me ha dejado pensando durante meses, seguramente muy influenciado desde mi posición de fundador. Esta parte especialmente

Do you maintain that same attitude towards risk and creativity nowadays?

— Right after school I started my own business in Gothenburg where I designed record slips. Following that, I moved to Stockholm to work in the advertising world until I was 25. I then started my first company, Acne. At that point, I had been so involved in everything I’ve ever done that I felt almost broken. At Teenage Engineering now we are about 60 and I understand that if you are involved in every little part of the business, it destroys you. So a few years ago I started to rebuild the organisation to essentially shoot me out of daily operations so now I can work on my own projects, and try to stay focused on the things I want to do. 

How has that rebuilding process been?

— I try not to share a vision but work on what may inspire people and teach them values to live a life they are happy with. If you’re not happy working with a specific subject, experiment, do something else

· Esta entrevista a Guenter Steiner. El menda tiene una aproximación a la gestión muy particular y un “me la sopla todo, yo voy a hacer lo que creo que está bien” que me encanta. No puedo dejar de criticar la forma de entrevistas en este podcast, siempre buscando la “lección rápida”, la frase “inteligente”, el topicazo de libro de autoayuda a las “3 cosas que blah blah” , qué forma de no sacar partido a sus entrevistados, qué cascarrabias me estoy haciendo.

· Otra entrevista más, en este caso a Amparo Llanos. Me da paz mental escuchar a esta mujer, irradia inteligencia. Dover para mi ha sido una banda brutal, no solo por su música, todo el producto es bueno: dos mujeres al frente, rompiendo cualquier tipo de esterotipo de cantante, cambiando de estilo musical cuando les dio la real gana y dejando el listón altísimo. De las cosas que no he hecho en la vida y me arrepentiré para siempre es no verlas tocar en directo.

· Dejo, por último, las dos canciones que más he escuchado este año, Ciaccona, interpretada por Alana Youssefian** **y L’Amour toujours tocado en un órgano de iglesia (en lo que parece ser una boda bastante mítica) a 22 dedos.

Y hasta aquí las cosas que se han fijado en mi cerebro, hay otras cientos de cosas, pero estas son las que han quedado.

Mis principios de ingeniería de datos

A menudo pensamos que hay una sola forma buena de hacer las cosas. La realidad nos dice una y otra vez que no es tan importante el camino si no la experiencia que tengas en hacer las cosas de la forma que hayas elegido.

Puedes ir por tu propia vía, tirar por una existente, una mezcla, da igual, la parte interesante no es lo que te da seguir una filosofía, es lo que no te quita, que es el tiempo en estar pensando que tu opción no es la adecuada. Posiblemente no lo sea pero nunca lo sabrás si no profundizas. Y si, insistir en tu propia forma de hacer las cosas ayuda.

Hay gente que se dedica a ir probando cosas sin profundizar y terminan haciendo cosas sin saber muy bien porqué. No se trata de cambiar nunca, se trata de explorar lo suficientemente lejos.

Mi carrera en los últimos años ha estado enfocada en al trabajo con datos, siempre en lo que me gusta llamar “alto rendimiento” y nunca había escrito los principios que sigo. Nunca está de más invertir un rato en explicárselos a uno mismo, por aquí los dejo.

Los datos tienen que servir un propósito.

Cuando generas datos deben tener un fin, y solo se deben generar los datos que van a ser útiles para eso.

No me creo que almacenar datos por almacenarlos sirva para algo, empresas almacenando datos sin valor. Y si el propósito último es almacenarlos, deberían cumplirlo a la perfección, es decir, ocupar poco, no consumir mucho, ser seguros, y sobre todo, ser capaz de eliminarlos cuando ya no sirvan.

Por eso no me creo mucho el “datawarehouse”, la de millones de € que se van en procesar y almacenar datos que nunca se usan es impresionante. Recuerda, la primera regla de cualquier ingeniero de datos es “el mejor dato es el que nunca se escribe, o mejor, nunca se genera”

Siempre que empiezo a diseñar un proyecto de datos lo hago por el mismo sitio: qué problema se quiere resolver, es decir, empezar por el final. Todos los proyectos que he visto donde se empieza por “pongamos tal tecnología”, “vamos a pensar en el modelo de datos y luego ya vamos viendo”, “hagamos un sistema genérico”, “guardamos en JSON y luego ya se verá” terminan mal y/o son carísimos.

Destilar, condensar y explicar los datos es un arte, aunque la mayoría de veces se usa una herramienta de BI.

Cualquier análisis sobre los datos debe ser rápido.

Los humanos funcionamos con el oído, la vista y otros sistemas que son prácticamente instantaneos, así debería ser cualquier cosa en la que una máquina que es mucho más rápida que un humano.

Programé videojuegos y 3D durante una temporada, en un juego tienes que hacer todos los cálculos en 16ms que es lo que dura un frame de una animación para que parezca fluida. De hecho empecé a programar gracias al código fuente del Quake (fue publicado en el 1999) que, aunque accede a una cantidad de información bastante grande, mantenía la velocidad incluso en aquellas máquinas. El código del Quake debería estudiarse en la universidad y dejarnos de tanta “programacion orientada a objetos”

El feedback debe ser instantáneo.

No solo se trata de que los datos sean rápidos, es que no debería pasar mucho tiempo desde que se generan hasta que se usan.

Un examen se puede estudiar todos los días o el último, adivina qué técnica es la mejor para aprender (que no tiene nada que ver con aprobar un examen)

Los datos sobre los datos son tan importante como los propios datos

Cuando las cosas pasan deprisa, tienes que saber qué está pasando, anticiparte, detectar cuando hay un problema, entender o símplemente quedarme mirando una gráfica que se mueve durante minutos por el simple hecho rendir tributo a la cantidad de cosas que tienen que pasar, de forma orquestada, para ver ese numerito en la pantalla.

Sí, es esto lo llamamos metadatos, y al ser meta, todas las reglas anteriores aplican.

Cómo preparo una charla

Siempre pensé que la gente que daba charlas eran expertos en la materia, nadie les podría toser, por eso estaban en un escenario hablando de algo y el resto, abajo, plebeyos, escuchando atentamente.

Si tienes una edad sabes que esto no es verdad, de hecho a veces los que más saben están abajo. Bueno, los que más saben están trabajando.

En cualquier caso, por suerte o desgracia he dado unas cuantas charlas de todo tipo. Me da una vergüenza absurda verme dando una charla, de hecho no vuelvo a ver mis charlas (ni podcast, ni nada donde haga me tenga que ver a mismo) nunca más, lo hecho, hecho está. Aún me asombra que me sigan llamando para hablar.

Dicho esto, dejo por aquí algunas cosas que he aprendido y sigo a la hora de preparar una charla. Tengo que decir que nunca repito una charla, reuso cosas, pero es raro que de una charla dos veces. Dar una charla tiene que ser divertido, tiene que tener un componente de emoción de la primera vez, de preparar la historia, de improvisar sobre lo que planteas.

Algunas reglas

La primera regla que sigo es: si me está llevando demasiado tiempo quiere decir que no sé suficiente de lo que voy a hablar y tiro la charla. Hay demasiadas charlas de mierda con gente que no tiene puta idea de lo que habla. Vale más una charla sencilla de algo que controlas a algo que no tienes ni puta idea, se nota, no te vas a ganar el respeto de nadie

En general si la charla es técnica lleva entre 3-5 veces más prepararla a si es inspiracional (sí, las que sueltas tu movida filosófica quitando cualquier detalle doloroso para dartelas de listo). Si tienes experiencia puedes preparar una charla en 1 hora o menos.

La segunda: lo que interesa es tu punto de vista del tema que hablas. No estás dando una clase de física teórica, estás hablando de tu experiencia y me interesa tu historia, como ves las cosas.

La tercera: para mi una charla tiene que sonar como si no fuese una charla, tiene que sonar a una conversación entre alguien y tú. Tienen que sonar a ti hablando normal, no como si estuvieses dando el tiempo. Esto lo aprendí cuando estaba dando una charla interna dentro de CARTO y un comercial me dijo “por qué ponéis ese tono de gilipollas al dar una charla, hablad normal”

La cuarta y más importante: las historias siempre ganan, tiene que haber un hilo narrativo con sus personajes (yo me escojo a mi familia y a mí mismo) su intro-nudo-desenlace. Personalmente me gusta hacer algo que aprendí en el fabuloso podcast sobre la serie Chernobyl , el director comentaba que para qué hacer esperar, era mejor arrancar con la explosión de la central, así que muchas veces empiezo por el final. BOOM, aquí lo tienes.

Otras cosas que tengo en cuenta:

Cuanto más corta la charla mejor. No hagas ni puto caso a los organizadores, si te dicen 30 minutos, haz 15 o los que creas necesario para contar tu historia, luego ya se verá. Si tardas más, qué va a pasar, van a llamar a la policía para sacarte del escenario? Eso sí, lo bueno si breve…

Añadir toques de humor siempre funciona. Bueno, no siempre, hay a gente que no le gusta, pero pueden irse a otra charla si quieren. Especialmente si intercalas para que la gente no muera. Además te sirve para medir cuanto de atenta está la gente, si se rien, es que va bien.

No seguir las tendencias es mejor. Cambia cosas.

Provocar a la audiencia es otro modo de mantener la tensión.

Yo cojo 3 ó 4 personas de referencia del público y les hablo a ellos. Una vez elegí a uno que se durmió (y luego preguntó durante el turno de preguntas el jeta)

Por ser claro, de lo que preparo luego uso la mitad porque luego improviso, quiero pensar que la improvisación funciona gracias a la preparación.

La parte más importante de todas es, como siempre, a nivel personal

Dar charlas es una forma de conocer gente, una excusa para hablar de algo que os une. Se hacen amigos, se aprende como otros hacen cosas, y das a conocer lo que haces.

Hay gente que te empieza a odiar también, no vayamos a idealizar. Una vez, por razones que no vienen a cuento, pude escuchar comentarios de una charla que di en Barcelona y os aseguro que duelen, especialmente porque los suelen ser personales y no sobre el contenido. Pero cuando subes al escenario, te expones a esto, es la vida. Yo también “odio”visceralmente a gente, sin razón aparente, luego conoces a la persona detrás del personaje y se te pasa.

Estar ahí arriba hace que tengas una oportunidad para poder empezar una conversación casi con casi cualquiera, aprovéchalo.

La respuesta al concurso del Lego de la TGR23

En esta TRG en Tinybird hicimos un concurso en el que tenías que adivinar el tiempo de una query SQL sencilla sobre 1 billón de registros. Si acertabas ganarías un LEGO que seguramente sea más difícil de montar que aprender SQL. El objetivo era no sólamente hacer un concurso estúpido para recoger “leads”, hacer algo que retase a la gente y a su vez sirviese para explicar qué hace nuestra empresa tenía más sentido. Además, si no sabes mucho de datos, te permite aprender.

Antes de escribir nada: es imposible saber el tiempo de ejecución de una query en un sistema donde desconoces todos los componentes. Bueno, aunque los conozcas, es en la práctica imposible. Así que era un juego de un mucho de estimación y otro mucho de suerte

El enunciado era tal que así:

“”” Responde con el tiempo que crees que tarda Tinybird en ejecutar esta query SQL

SELECT 
    toDate(timestamp) AS date, 
    avg(speed) AS avg_speed
FROM rocket_telemetry 
GROUP BY date

La tabla se le añaden 1000 registros por segundo y en el momento del comienzo de la TRG23 tenía 1 billón americano de registros.

HINT: es más rápido de lo que crees. “””

Como ves, sin conocer datos tan básicos como cual es el sistema que corre, como almacena los datos, el esquema de la tabla etc etc es absolutamente imposible. Aún así, vamos a hacer un análisis de como se podría estimar sin ponernos muy técnicos, en términos simples.

Empecemos por los básicos: el tiempo de una query tan sencilla depende del tiempo que tardemos en leer los datos. Esto es así para la gran mayoría de queries que son ejecutadas en nuestras queridas bases de datos.

Así que en el caso que nos atañe tenemos dos columnas, vamos a asumir que son de 4 bytes cada una (un campo Date y otro Float), a la hora de ejecutar la query había unos 1.1b de registros, tenemos un total de ~8.2Gb (=1000000000 * 4 * 2). Mi portátil, macbook pro M1, es capaz de leer aproximadamente unos 3.8gb/s de memoria cuando todos los registros están perfectamente colocados, no tengo ni pajolera de lo que tardará un servidor de google -donde estaba alojada mi cuenta de tinybird- pero entiendo que es algo similar, así que la query debería tardar algo más de 2 segundos.

No tan rápido, en realidad nosotros somos más listos que eso, en la tabla había un timestamp, y en enunciado dice que son unos 1000 registros por segundo. Debería haber usado un timestamp de 64 bits, pero no lo hice (mal), pero en este caso, sabemos que hay 1000 valores seguidos iguales si los vamos colocando en la base de datos según nos los envían.

Y si en vez almacenar el valor, almacenamos la diferencia con el valor anterior? Pues vamos a tener 1 uno, seguido de 999 ceros. No sé a ti, pero a mi me da que eso se puede guardar de una forma eficiente. Alguien ya se dio cuenta hace años he inventó algo llamado RLE compression, que permite reducir la cantidad de información cuando se repiten mucho los valores. En este caso, usé un algoritmo algo más moderno, LZ4. La historia de LZ4 es bastante increíble, os recomiendo este podcast.

Echando cuentas, si guardamos 1 uno y 999 ceros, repetido 60 segundos * 60 minutos * 24 horas son básicamente 1kb que es tamaño que ocupa 1000 valores y otro más para decirle las veces que lo tiene que repetir. En la base de datos que usamos, Clickhouse, ocupa unos 22mb. Lógicamente hay ineficiencias porque el sistema de almacenamiento no está pensado para este caso de uso, ni LZ4 funciona exactamente como he dicho. Aún así, de 4gb a 22Mb podemos decir que hemos hecho un buen trabajo.

Entonces ahora tenemos dos columnas, una de ellas, timestamp, que ocupa 21mb y otra, speed que ocupa 4gb. Dirás, por qué no se comprime esa columna? Pues porque usé un rand() que por definición apenas comprime. La realidad es que usando ZSTD, otro algoritmo de compresión, se queda en aproximadamente 3.8gb. Es importante saber donde es fuerte cada algoritmos de compresión, no tienes que saber los detalles, pero sí tener intuición.

Para terminar, echando cuentas, la query debería tardan aproximadamente 1 segundo, y efectivamente, así era. De las 224 personas que participaron, menos de un 5% dieron una respuesta entre 0.5 y 1.5 segundos, menos de 10% si muevo el rango de 500ms a 3s.

Pero aquí no termina todo, a nada que sepas SQL podrás intuir que para ejecutar esa query no necesitas leer todos los datos todas las veces que ejecutes la query, puedes ir agregando a medida que vienen los datos. SI estás pensando ahora mismo en “pongo un scheduler que se ejecute cada minuto” o “uso spark whatever” o “snowflake blabla” siento decirte que la tecnología ha avanzado en estas últimas 3 décadas y ahora las cosas se pueden en tiempo real. Bueno, procesar 1000 registros cada segundo se puedía hacer hace unos 30 años en cualquier PC, va a hacer 30 años de la release de DOOM, amigos (para los milenials, DOOM era nuestro Fortnite)

Así que si agregas según vienen los datos, necesitas almacenar unos 12 días (aprox 100M de eventos al día son generados a 1000 ev/s) con lo cual necesitas una tabla de 12 filas con 3 columnas: fecha, suma total, count. Eso son unos 144 bytes si usas 4 bytes por cada tipo de dato.

Con ese dato puedes intuir que la query está por debajo de 1 milisegundo casi con total seguridad, lo que se tarde en parsear la SQL y poco más. Si tu sistema tarda en parsear la query y coger 120bytes (~8kb en Clickhouse) más de 1ms, me jode ser yo el que te lo diga, pero hay algo que hay que repensar.

Solo 8 personas respondieron 1ms o menos. De hecho la query total costaba unos 0.8ms, ganó Claudia que puso 0.99 :)

Si has llegado hasta aquí es porque el tema te interesa. Hice un curso de unas 3 horas explicando en detalle todo esto, lo puedes ver por aquí.

Gracias por pasar por el stand de Tinybird, fue un placer hablar con vosotros.