During the first 4 years of Tinybird (the company I founded) I’ve been helping our customers on the technical side (pre and post sales). I’ve probably talked to more than 100 companies and actively helped +50, ranging from those with just a few employees and Gigabytes of data to top companies in the world with Terabytes.
Tinybird (bear with me, this is not a post about the product) helps solve specific projects, and most of the use cases we had to deal with were not just about building a data platform but also refactoring what the company already had to meet real-time requirements. I think helping these companies change their mindset has saved them millions of dollars a year.
Some clarifications before I start: when I talk about real-time, people think about Kafka, Spark, Flink, etc. But reality means “what you were doing before, but actually fast” or “what you were doing before, but without having to go take a coffee when you run the pipeline”. I like to call it “high performance data engineering”. It usually means:
Some practical learnings, in no particular order:
People think doing traditional ETL fast is not possible. Most people think pipelines that process a lot of data should take hours. The reality is that most cases can be solved in real-time (<1s query time) with less hardware. Good design always beats hardware.
The vast majority of projects save data that is never used (sometimes more than 90%). And they process it. Every single day/hour/minute. There is no one thinking about that.
People focus on learning the tools, which is good, but they forget about principles. I can’t count the number of times I’ve seen someone doing a SQL query that could run 1000x times faster just by sorting the data in the right way. The thing is: they know how to use Spark/Snowflake/BigQuery perfectly but never spend an afternoon understanding how those things work under the hood. And believe me, there are 3-4 basic concepts that get you to 80% of what you need to know. I spent 7 years of my life handling a massive Postgres cluster and never spent enough time understanding how it works. I now forgot about how to use Postgres but I’m pretty sure I would have remembered if I had spent more time understanding the principles.
Most projects think data will always be right and you won’t need to fix it. Everybody, again, everybody makes the mistake of loading the same data twice. It does happen, all the time, and if you didn’t think about it your ETL will be hell and you’ll spend a lot of time fixing data in production.
Ingestion is 80% of the job but usually it’s not even monitored. There are 100 ways for an INSERT to fail or be slow. The data you are not able to ingest breaks all your pipeline and those errors are silent. You see data in your SQL queries and realize there’s a problem when it’s too late and too big.
Data quality is like unit testing but in production. Testing your pipelines in the CI (and just 10% of people do it) is not enough, you need continuous monitoring.
There is always a schema. You decide on it when you write the data or later when you read it, but at some point, you need to decide attributes and data types for your data. JSON is nice for some cases but it’s not a solution. Actually, any serious data pipeline gets rid of JSON as soon as possible. JSON makes projects 2-10x more expensive just on hardware. Not going to talk about the countless hours spent on guessing the JSON schema.
Yes, there are projects where having an open schema is needed but schemaless at scale is super expensive and usually you need to split your workload logic between the common use cases and the long tail. In other words, if you allow your customers to send anything, be ready to fight for those 0.0000001% events that have that 3MB attribute :)
Fast, cheap, flexible. Pick two.
If you want to keep your +p99 latencies low, you need to have your hardware idling most of the time.
end to end to end latency = K / $. You want your data to be available as soon as possible, you need hardware. And it’s not a linear function, you need to push a lot of money to go from 10s to low seconds (keeping your reading latencies low, otherwise, what’s the point)
People always think their operations will finish OK. Following an immutable workflow plus atomic operations always saves you days of fixing wrong or partial data.
Most people don’t have an intuition about what current hardware can and can’t do. There is a simple math that can help you with that: “you can process about 500MB in one second on a single machine”. I know it’s not a universal truth and there are a lot of details that can change that but believe me, this estimation is a pretty good tool to have under your belt.
Let me finish with this, and it hurts: Most companies just need basic bash / make knowledge, a single instance SQL processing engine (DuckDB, CHDB or a few python scripts), a distributed file system, git and a developer workflow (CI/CD). Everything else is sugar and enterprise stuff. Not saying these last ones aren’t important, but the basics should be well covered, otherwise you’ll have a huge mess. I’m still surprised by how quickly we forget about the good practices we have learned over the years in software engineering (testing, deployment, collaboration, monitoring and so on)
I learned a lot more things about people itself, but that’s another story.
No puedo asegurarlo pero tampoco tengo muchas dudas que la gente que trabaja en mi equipo piensa que soy gilipollas por “apretar” todo el rato con las fechas de entrega. Cada nueva cosa que arrancamos siempre digo lo mismo: “si podemos tener algo visible mañana mejor que pasado, pero lo ideal serían un par de horas”, “si dudas, mejor avanza” y otra serie de cosas que intento transmitir, habitualmente con poco éxito, aunque no será pos ser el brasas.
Cualquiera que trabaje en el mundo del software sabe por mucho que aprietes, da igual, tarde o temprano terminas inviertiendo el tiempo que se necesitaba. Como todo lo bueno, y no es diferente en esta industria, necesita mucho tiempo. Entonces, por qué soy el gilipollas que aprieta con el plazo, que negocia cada paso del proyecto, que pide buscar compromisos en la “calidad” todo el rato ? es muy fácil: en un producto como en nuestro la mayor parte del tiempo no sabes bien lo que estás resolviendo, la falacia de que sabes dónde tienes que ir es la peste de la industria del software, especialmente en el mundo startup.
Nosotros no somos una empresa que haga “commodity”, estamos haciendo algo que no es lo que hace la industria pero un poco diferente, tratamos de simplificar algo que lleva 40 años haciéndose de la misma forma. Las bases de datos han llegado a un punto donde ya no hay mucha mejora relativa a la mejora del hardware y nuestro plan es hacer que las cosas sean más fáciles. Así que si crees que sabes lo que realmente estás haciendo en un entorno así es que o confías mucho en ti o eres demasiado “junior” (odio este concepto pero lo pongo por hiriente)
“Apretar“ no es más que una forma de poner lo que estás haciendo delante del usuario (bueno, y delante tuyo también, que a veces es importante ver la mierda que has hecho) lo antes posible. Esto no es nuevo, es lo que llaman feedback rápido; en este caso trato de que sea fugaz, visceral, como cuando un músico saca la guitarra y toca, sin importar los fallos, un poco desafinado, lo que luego será una obra bien tocada, arreglada y perfectamente producida. La esencia es la misma, la canción la vas a reconocer, y si te gusta en crudo, te va a gustar “a lo grande”. El mejor ejemplo actual de esto es Tesla, el Cybertruck a nivel de standard de calidad de fabricación es absurdo, pero seguramente se dieron cuenta pronto que esa parte no es la importante (recomiendo este video donde explican el drama en detalle)
Cuesta, no es trivial plantear la mínima expresión de producto, desarrollar sabiendo que dejas cadáveres por el camino, mucha gente ni sabe ni quiere hacerlo pero es fundamental: si tardas 3 meses en poner en algo producción, has consumido el 15-20% de lo que dura una ronda de financiación de una startup, solo tienes 6 balas y te aseguro que 6 intentos son demasiado pocos. Y el desarrollo es lo de menos, es toda la cadena de marketing, ventas, etc que viene detrás tuyo. Del mismo modo, este tipo de “features” no se pueden desarrollar usando un proceso habitual, necesita que haya poca gente tomando decisiones, que al resto del equipo le “moleste” un poco, necesita que la política y las opiniones no estén en el camino (y ahora entiendes el porqué de la innovación en las grandes empresas)
La literatura no sirve aquí, el proceso tampoco, lo único que sirve es llegar cuanto antes para ver lo que hay y volver rápido a contar lo que has encontrado. Bueno, en realidad la literatura del software nos lleva diciendo años que tenemos que iterar rápido, pero nos empeñamos en montar castillos en el aire para intentar solucionar un problema demasiado complejo para arreglarlo proceso.
Por último, no entiendo a la gente que no disfruta del subidón de tener prisa por poner algo en producción :)
Ayudo a hacer los deberes a mi hija de 6 años, esas cosas que la modernidad nos ha traído. Mis padres nunca me ayudaron y así creo que debería ser, no va a haber nadie para sacarles las castañas en 10 años. Es de las cosas más aburridas que alguien puede hacer, ver como alguien las pasa putas para hacer una suma trivial o leer una frase con 5 palabras de 6 letras cada una es horroroso y si tienes poca paciencia te llevan los mismos demonios. Sé que son 6 años, pero aún así duele.
No todo es malo (no soy tan mal padre) tiene cosas interesantes. Ver como un humano aprende cuando viene de la nada es absolutamente maravilloso. No tener ni la menor idea de las reglas establecidas, unido a que un niño de 6 años es como un adulto pero borracho todo el día, hace que salgan por peteneras continuamente, enlacen temas totalmente descorrelados, entienden diferente. Los problemas suelen ser cerrados. Marca la respuesta correcta. Dos más tres. Une las relacionadas. Nada se deja al azar. Tiene sentido, si la cantidad de atención que un niño es reducida, imaginate si además no le pones puertas al campo.
El problema de esto es que durante toda la etapa educativa se mantiene así. Vas al examen, te ponen un problema y te quejas si “este contenido no lo hemos dado en clase” en el mejor de los casos. Solo hay una cosa peor que esto, son los exámenes tipo test, que parece más un sudoku que algo que demuestre que sabes de lo que estoy hablando. Seguramente tenga sentido, ahorra tiempo de corrección y uniformiza la forma de medir a todos los alumnos. Nadie puede destacar en los suyo, todos en la media, tema resuelto. Desconozco si el cambio del sistema universitario hace unos lustros mejoró esto, pero no me da la impresión.
Y el tema es que el mundo real no es así. Para luchar contra esto le digo a mi hija que cuando no sepa algo o dude ponga una nota al margen con lo que ella piensa. Son notas muy ingenuas pero por lo menos deja una pequeña puerta abierta a que razone, a que no haya una sola forma de hacer las cosas y abre una puerta a la conversación con el “otro lado”. No diré que no cuesta hacerle escribirlas, pero es seguramente lo único que saque de beneficio.
Llegamos a la edad adulta y hemos vivido en un mundo donde todo son preguntas cerradas y respuestas que no se pueden salir del guion, en el momento que hay folio en blanco o el problema que queremos resolver es muy abierto, tan abierto que ni siquiera la propia definición del problema puedes darla por completa, estamos absolutamente vendidos.
Y toda esta explicación para llegar a los procesos de selección en las empresas. En el proceso de contratación que sigo, hay siempre una prueba técnica. Esta prueba (por aquí un ejemplo) es una frase vaga con un problema muy mal definido y cuales van a ser los criterios de valoración. El principal es sobre el proceso de decisión, no tanto el resultado.
La mayoría de la gente va sobre railes. Resuelve el problema sin hacer ni una sola pregunta, sin hacer “challenge”, como si no se pudiese cambiar nada, como si no hubiese margen para negociar y entender las razones. No preguntan o preguntan para responder y no para entender. No se dan cuenta que resolver un problema es un proceso de iterar con otra gente, de acotar el problema hasta que acorrale a la solución. A veces no hay solución y hay que llegar a un compromiso. Nada de esto se enseña en el proceso educativo donde todo tiene su respuesta y lo tenemos metido hasta el mismo bulbo raquídeo, al lado de la función de respirar.
Intentando simplificar la vida de mucha gente en la etapa de aprendizaje, en realidad les estamos complicando la vida. Prefiero que mi hija suspenda en un acto de “rebeldía” a que se acostumbre a no tener una visión crítica o pensar, como dicen ahora, “fuera de la caja”.
Mi padre a mi actual edad ya estaba enfermo. En realidad lo estuvo desde que tomó su primera gota de alcohol, pero a sus 42 ya tenía todo firmado y listo para zarpar. Aún así el cáncer tardo otros 3 largos años en pasar a recogerle, es increíble lo que aguanta un cuerpo humano.
Durante los últimos meses él era consciente de que se moría, no parecía importarle, es como si ya estuviese preparado para eso. En ese tiempo tuve la única conversación verdaderamente profunda de nuestra vida: se despidió y me pidió perdón por ser un mal padre. Realmente lo fue, no era falsa modestia, pero no deja de honrarle, podría haberse ido sin decir nada.
Por esto y otros antecedentes similares en la familia no pasa un mes sin que piense en el momento de que algún médico, después de una prueba sin mucha importancia me diga que ha visto algo raro y no hace falta que os cuente lo que pasa después. Se puede decir que llevo unos 25 años preparándome para ese día.
Aún no estoy enfermo -aparentemente- así que es probable que viva más que mi padre, pero no puedo dejar de pensar en que puede que no me queden muchas balas que disparar. Ya lo sabía de hace tiempo, pero llegar a los 40 te debe activar meter un x10 en la sensibilidad de estas cosas.
Me encanta lo que hago y tengo una sensación entre rabia y pena al pensar que me quedan muy posiblemente pocos tiros que pegar. Incluso aunque vivas hasta jubilarte, el tipo de cosa que hago ahora (empresas de tecnología) no suelen ser para señoros de 55 años. No digo que no lo puedas hacer, seguro que sí, pero si estás leyendo esto y tienes 30 años, la energía se acaba y a los 40 ya no te sale de las narices hacer según que cosas. Y te lo dice alguien que come mierda a paladas a diario. Por otro lado la cantidad de tiempo que tienes que invertir en seguir bien crece mucho, salvo que Dios te haya tocado con la varita mágica, y eso reduce aún más el tiempo efectivo.
Todo esto hace que me pregunte casi a diario si lo que hago es lo que debería estar haciendo, si estar moviendo datos de un lado para otro va a mover alguna aguja o si no estaré cambiando mi tiempo por un puñado de dólares sin propósito alguno. Imagino que a todo el mundo le llega un punto en la vida en el que se hace esta pregunta, aquí lo dejo yo por si a ti te ha pasado, que sepas que no eres el único.
Lógicamente a nivel personal hay otras miles de cosas que me matan pero no has venido aquí a que te cuente mi vida.
Tenía unos 20 años y frecuentaba canales de IRC en el irc-hispano -el discord de antes, de cuando internet no estaba optimizado- de programación de videojuegos y 3D. Uno de los chavales allí me mandó una demo, era un patito de juguete modelado en 3D girando con iluminación “por pixel”. A día de hoy eso te lo programas en 10 minutos con cualquier motor 3D y chatGPT, pero en aquel momento era bastante impresionante, teniendo en cuenta que por aquella época no tenía tarjeta gráfica. Agradezco enormemente que Unai aguantase mis gilipolleces de novato y tuviese la paciencia para hacerme algo de caso.
Algo en mi interior me empujó a ponerme a trabajar para aprender a hacer tal maravilla y me metí en la programación de videojuegos y 3D de lleno. Desde pequeño me encantaron los videojuegos, al nivel de que mi primera gran “travesura” fue gastarme 13 mil pesetas (unos 300€ hoy) en una Master System sin decir nada a mis padres. No fue sencillo, en mi pueblo no podías comprarla, así que me tocó engañar a una persona para que me la comprase en “la gran ciudad”. Nunca más he vuelto a ser tan bueno engañando a alguien, ni siendo comercial como ahora. Los incentivos, bien diseñados, son maravillosos.
Perdonad, no me lio más. Cuando programas un videojuego la pantalla se tiene que actualizar unas 60 veces cada segundo para que parezca fluido, es decir, cada 16.6 milisegundos tienes que hacer los cálculos para que todo lo que está en la pantalla se mueva y se dibuje.
En términos absolutos, para una CPU actual, 16 milisegundos es la enternidad, pero la realidad es que a día de hoy la mayoría de desarrolladores no son capaces de devolver una respuesta a una llamada sencilla de un navegador web en 10 veces ese tiempo, cosa que es un órden de magnitud más sencillo (y estoy siento generoso para que los desarrolladores web no se sientan heridos)
El hecho de tener esa restricción pone el listón muy alto desde el principio. No puedes pensar en solo resolver algo además, por defecto, tiene que ser rápido o no va a funcionar. Eso hace que aprender a programar sea especialmente difícil, es el campo de entrenamiento más duro posible. Seguramente la gente que haga High Frequency Trading esté en una situación similar, pero dudo que nadie se ponga de niño a programar HFT por gusto.
Terminé haciendo 3D y videojuegos durante los primeros años de mi carrera. No me pagaban mucho, pero me daba igual, era mi sueño y cada uno pone a sus sueños el precio que quiere. Bueno, no solo eso, además hacía videojuegos y demos (algunas de ellos, además, con una restricción de 4kb de tamaño total) en mi tiempo libre, que seguramente debería haber invertido en hacer deporte y conocer gente (*)
Al cabo de los años, cuando la vida te lleva a otras industrias y ves que la gente no se ha formado con esa restricción, que nunca han tenido que hacer alto con limitaciones de tiempo, no te encaja su forma de plantear las soluciones, todo es un desperdicio. Cuesta entender el porqué esa gente hace las cosas sin pensar en que tiene que estar dentro de esos 16ms. En realidad ves como la mayoría de gente ha vivido la mayor parte de su vida laboral en vacas gordas que es de las peores cosas que te pueden pasar a nivel profesional. La industria del software está un par de órdenes de magnitud en eficiencia de donde debería estar, incluso después de 20 años de locura.
Lógicamente al cabo de los años uno se acostumbra a la buena vida y te olvidas de ser eficiente alegremente. La parte buena es que has vivido en el infierno, sabes como llegar y que puedes quedarte allí a vivir cómodamente. Así que si tienes la oportunidad, búscate tus “16 milisegundos” particular.