javisantana.com

@javisantana ABOUT

LLMs to transform data

I transform data every day and I usually do 2 kinds of transformations, changing the data format so I can use it in a tool (CSV to parquet) or the shape of it, like running an aggregation so I can understand it. I’m using LLMs more and more for this because it saves me a lot of time (and it’s cool)

I see two approaches for using LLMs to transform data:

Asking to transform the data and output it

cat file | llm —system "transform the data into <format>"

Asking to generate code to transform the data

cat file | llm —system "generate a python code to transform this data into <format>" > trasform.py && \
python trasform.py file > transformed

If you don’t know what the llm command is, please, go to check the fantastic llm cli tool from

The second one has many benefits:

The code will run way faster, LLMs are still slow compared to regular CPUs

The transformation can be audited and fixed

Let’s test it. I have a file with NMEA records. NMEA according to Wikipedia “is a combined electrical and data specification for communication between marine electronics such as echo sounder, sonars, anemometer, gyrocompass, autopilot, GPS receivers and many other types of instruments”. if NMEA was invented today, it would have been NDJSON but at that time machines were sending data through a 9600 bauds per second comm line.

Anyway, I have some data I got from my car’s GPS (which still send the info using NMEA these days), filter RMC sentences (the ones that have the coordinates) and pipe into the llm command (using gemini-2.0 code execution). This would be the command (I shortened it for clarity)

 ✗ head -n 40 cheste_fixed.nmea | grep RMC | llm  -m gemini-2.0-flash-exp -o code_execution 1 --system "write and EXECUTE a program to parse that data and generate ndjson with lat, lon, time and speed attributes. No explanations, just write and execute"

import json
import re
from datetime import datetime, timedelta

data = """
$GPRMC,172633.00,A,3929.0184,N,00037.8573,W,80.7,54.1,160923,,*22
$GPRMC,172634.00,A,3929.0331,N,00037.8280,W,84.0,55.5,160923,,*24
$GPRMC,172635.00,A,3929.0495,N,00037.7985,W,93.5,54.8,160923,,*22
...
"""

def parse_nmea(line):
    match = re.match(r'\$GPRMC,([\d.]+),A,([\d.]+),([NS]),([\d.]+),([EW]),([\d.]+),([\d.]+),(\d+),,', line)
    if match:
      time_str, lat_str, lat_dir, lon_str, lon_dir, speed_str, _, date_str = match.groups()

      time_obj = datetime.strptime(date_str+ time_str.split(".")[0], "%d%m%y%H%M%S")


      lat = float(lat_str[:2]) + float(lat_str[2:]) / 60.0
      if lat_dir == 'S':
          lat = -lat
      lon = float(lon_str[:3]) + float(lon_str[3:]) / 60.0
      if lon_dir == 'W':
         lon = -lon

      speed = float(speed_str) * 1.852

      return {
          "lat": lat,
          "lon": lon,
          "time": time_obj.isoformat(),
          "speed": speed
      }
    return None


parsed_data = []
for line in data.strip().splitlines():
  parsed_line = parse_nmea(line)
  if parsed_line:
    parsed_data.append(parsed_line)

for item in parsed_data:
  print(json.dumps(item))

{"lat": 39.48364, "lon": -0.630955, "time": "2023-09-16T17:26:33", "speed": 149.4564}
{"lat": 39.483885, "lon": -0.6304666666666667, "time": "2023-09-16T17:26:34", "speed": 155.568}
{"lat": 39.48415833333333, "lon": -0.629975, "time": "2023-09-16T17:26:35", "speed": 173.162}
{"lat": 39.48441833333333, "lon": -0.6294983333333334, "time": "2023-09-16T17:26:36", "speed": 177.9772}
{"lat": 39.48466666666667, "lon": -0.6290183333333333, "time": "2023-09-16T17:26:37", "speed": 177.9772}
{"lat": 39.48491666666666, "lon": -0.628515, "time": "2023-09-16T17:26:38", "speed": 179.27360000000002}

It feels like it did the right transformation (indeed, checking the data, it’s accurate). Just in case you are checking the data carefully, speed attribute feels like to high but it’s a car in a race track, so it’s expected.

But how could we make sure it’s doing it right? let’s use what we have been using in software development for years: tests. So let’s ask the LLM to generate not just the transform, but also the test.

$ head -n 10  ~/Downloads/lap_timer/cheste_fixed.nmea | grep RMC | llm  -m gemini-2.0-flash-exp -o code_execution 1 --system "write and EXECUTE a program to parse that data and generate ndjson with lat, lon, time and speed attributes. Also write the code that transforms the output back to original format and check the transformation back. No explanations, just write and execute"

import json
import pynmea2
from datetime import datetime, timedelta

nmea_data = """$GPRMC,172633.00,A,3929.0184,N,00037.8573,W,80.7,54.1,160923,,*22
$GPRMC,172634.00,A,3929.0331,N,00037.8280,W,84.0,55.5,160923,,*24
$GPRMC,172635.00,A,3929.0495,N,00037.7985,W,93.5,54.8,160923,,*22
$GPRMC,172636.00,A,3929.0651,N,00037.7699,W,96.1,54.8,160923,,*28
$GPRMC,172637.00,A,3929.0800,N,00037.7411,W,96.1,55.5,160923,,*2D"""

def parse_nmea_to_ndjson(nmea_str):
  ndjson_output = []
  for line in nmea_str.strip().splitlines():
    try:
      msg = pynmea2.parse(line)
      if isinstance(msg, pynmea2.RMC):
          time_obj = datetime.combine(msg.datestamp, msg.timestamp)
          ndjson_output.append(json.dumps({
              "lat": msg.latitude,
              "lon": msg.longitude,
              "time": time_obj.isoformat(),
              "speed": msg.spd_over_grnd
          }))
    except pynmea2.ParseError:
      print(f"Could not parse: {line}")
      continue
  return "\n".join(ndjson_output)

def transform_ndjson_to_nmea(ndjson_str):
    nmea_output = []
    for line in ndjson_str.strip().splitlines():
        try:
            data = json.loads(line)
            time_obj = datetime.fromisoformat(data['time'])
            nmea_time = time_obj.strftime("%H%M%S.%f")[:-3]
            nmea_date = time_obj.strftime("%d%m%y")

            lat_deg = int(abs(data['lat']))
            lat_min = (abs(data['lat']) - lat_deg) * 60
            lat_dir = "N" if data['lat'] >= 0 else "S"

            lon_deg = int(abs(data['lon']))
            lon_min = (abs(data['lon']) - lon_deg) * 60
            lon_dir = "E" if data['lon'] >= 0 else "W"
            
            nmea_speed = data['speed']
            
            nmea_str = f"$GPRMC,{nmea_time},A,{lat_deg}{lat_min:.4f},{lat_dir},{lon_deg}{lon_min:.4f},{lon_dir},{nmea_speed:.1f},{nmea_speed:.1f},{nmea_date},,"
            
            checksum = 0
            for char in nmea_str[1:]:
                checksum ^= ord(char)
            nmea_str += f"*{hex(checksum)[2:].upper()}"
            nmea_output.append(nmea_str)
            
        except json.JSONDecodeError:
            print(f"Could not decode json: {line}")
            continue
    return "\n".join(nmea_output)

ndjson_data = parse_nmea_to_ndjson(nmea_data)
print("NDJSON output:")
print(ndjson_data)

nmea_transformed = transform_ndjson_to_nmea(ndjson_data)
print("\nTransformed back to NMEA:")
print(nmea_transformed)

print("\nOriginal NMEA:")
print(nmea_data)

def check_transformation(original, transformed):
    original_lines = original.strip().splitlines()
    transformed_lines = transformed.strip().splitlines()

    if len(original_lines) != len(transformed_lines):
        print("Number of lines do not match.")
        return False
    
    for orig_line, trans_line in zip(original_lines, transformed_lines):
        try:
            orig_msg = pynmea2.parse(orig_line)
            trans_msg = pynmea2.parse(trans_line)
            if not isinstance(orig_msg, pynmea2.RMC) or not isinstance(trans_msg, pynmea2.RMC):
                print("Message type is incorrect.")
                return False

            if not (abs(orig_msg.latitude - trans_msg.latitude) < 0.00001 and
                   abs(orig_msg.longitude - trans_msg.longitude) < 0.00001 and
                   abs(orig_msg.spd_over_grnd - trans_msg.spd_over_grnd) < 0.0001 and
                   orig_msg.timestamp == trans_msg.timestamp and
                   orig_msg.datestamp == trans_msg.datestamp
                   ):
                print(f"Original: {orig_msg}")
                print(f"Transformed:{trans_msg}")
                return False
        except pynmea2.ParseError:
            print(f"Could not parse: {orig_line} or {trans_line}")
            return False
    print("Transformation check passed!")
    return True

check_transformation(nmea_data, nmea_transformed)

ExecuteCode failed: MODULE_NOT_FOUND.
msg_err: Traceback (most recent call last):
  File "<string>", line 3, in <module>
ModuleNotFoundError: No module named 'pynmea2'

It fails to run because of the pynmea2 but if you run it locally it manages to do it. So running that self-test gives us some confidence about the transformation function and I’d trust it to be in a pull requests.

BTW, using the first approach also work, at least for gemini 2.0 it manages to transform NMEA to JSON right, but it take way more time than generating the script (as expected)

Learnings after 4 years working with +50 companies on data engineering projects

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:

  1. Lots of data (more than dozens of millions of rows a day with a few years of history, usually Terabytes)
  2. Low latency end to end (so no or lightweight ETL)
  3. Sub second queries, usually <100ms
  4. Reasonable costs (similar to or lower than traditional ETL)

Some practical learnings, in no particular order:

I learned a lot more things about people itself, but that’s another story.

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.

Customer Success

Llevo unos meses liderando lo que llamamos en Tinybird un equipo de “Customer Success”. Antes se llamaba de otra forma que ni recuerdo.

Cambié el nombre porque me parecía que lo que realmente hacíamos era eso, ayudar a los clientes a salir del paso, a quitar la roca del camino, a llegar a puerto, a luchar contra el enemigo comun, a poner en producción vaya. Siendo nuestro producto algo pensado para desarrolladores no veo otra forma más clara de tener “success” que esa.

Resulta que, después de unos meses de ver a la gente que llegaba nueva a la empresa totalmente contrariada, tuve que crear una presentación para explicar quién leches éramos, qué hacíamos y el porqué en vez de ser comerciales, somos un equipo de ingeniería.

Ahora, leyendo sobre el tema (1) y escuchando los sermones (2) de la gente que sabe del sector, veo que la métrica habitual de “Customer success” es incremendar la facturación. Nunca en mi cabeza pondría una métrica que no estuviese alineada con un cliente, pero es que resulta que esta métrica define prácticamente lo que hace el departamento. Y seguramente sea así por una muy buena razón que desconozco, imagino que a escala simplifica todo.

Así que, muy a mi pesar -ya me había costumbrado- cambiaré el nombre de nuevo, aunque sigamos haciendo lo mismo. Eso antes de poner un objetivo absurdo.

Lo complicado de esto es que el equipo no encaja en ninguna definición existente en el panorama startup. Así que o bien busco lo más parecido y me hago otra presentación para explicarlo o pongo una métrica de facturación o le pongo un nombre que genere GPT-3 en base a la descripción.

Puedo comprender el porqué las empresas tratan de poner nombres standard a departamentos, igual que se lo ponemos a los roles, pero la realidad es que tal vez estemos ajustando la empresa a los nombres y no los nombres y funciones a la realidad de la empresa y el producto. Por eso cuando veo que alguien define una oferta de trabajo por lo que hay que hacer y no por el título, incluso si la descripción es vaga, me da sensación de “esta gente sabe lo que se hace”.

(1) La wikipedia acierta bastante con la definición, la verdad.

(2) Me refiero a la primera acepción “Discurso cristiano u oración evangélica que predica el sacerdote ante los fieles para la enseñanza de la buena doctrina.”. La “buena doctrina”, ya sabes.

Alma

En el año 1999 un fulano se presentó al rally París-Dakar con un coche perdedor. El Dakar es un rally que dura unas dos semanas, pasa por caminos de cabras, dunas y otras tantas sendas donde un coche de calle no avanzaría ni un palmo.

Era perdedor porque no era 4x4, así que pasar las zonas de dunas era complicado y no tenía un equipo oficial detrás para reparar el coche después de cada etapa, ni que decir tiene que tampoco para meter la gallina en diseño y desarrollo del coche previo al rally. Hizo todo lo contrario de lo que ponía en el libro de los ganadores.

Pero lo ganó. El coche no era 4x4 pero gracias a eso era más ligero, más sencillo de reparar y tenía sistemas para hinchar y deshinchar las ruedas sin bajarse del coche que le permitían pasar las dunas fácilmente (a menos presión en las ruedas, menos te hundes en la arena). Había aprovechado el reglamento al máximo pensado para las grandes marcas que llevaban coches 4x4, los que el sentido común decía que todo el mundo llevaría.

Era un coche con alma. Y no porque ganara, si no porque el menda llevaba 10 años compitiendo con este tipo de coches (y otros 20 en otras categorías, como F1), que él mismo diseñaba. Creía en su idea y punto.

Schlesser ganó pero hay mucha gente que se cree sus ideas y nunca “gana”. Da igual, no se trata de ganar, esto no es David contra Goliat (aunque cuando lo son es aún más placenetero)

A lo largo de los años, sin realmente buscarlo mucho, me he dado cuenta que me han dejado de gustar las cosas que no tienen “alma”. Como decía Bukowski, “no tengo tiempo para cosas sin alma”. No tenía claro qué era, pero había llegado un punto que prácticamente rechazaba de forma inconsciente algo si era “mainstream”. Necesito el toque personal para que algo me resulte interesante.

Para que nos entendamos, es básicamente lo que está en el polo opuesto de “corporativo”.

Así que en vez de ver series en Netflix termino viendo videos de un fulano con 200 suscriptores grabando videos desde su granja, termino comprando a tiendas solo porque los que lo regentan son unos personajes, leo biografías de gente que hicieron las cosas de otra forma, conduzco un coche que nadie en sus cabales conduciría más allá de 100 kilómetros y uso tecnología que nació desde una necesidad y una convicción, no como forma de conseguir con objetivo.

Todo tiene un precio, habitualmente el fulano con 200 suscriptores postea 1 vez cada 3 meses en vez de tener un episodio semanal, las tiendas son más caras y los coches se rompen más, y te miran raro cuando dices que no usas kubernetes, pero la sensación de estar usando algo hecho con convicción vale seguramente mucho más que todo eso.

Lamentablemente, bueno, no, afortunadamente, las cosas con alma no suelen escalar y suelen perder el alma cuando se hacen por dinero. Así que hay que aprovecharlas mientras duren.

Solo necesitas saber esto para escalar rápido tu equipo técnico.

No son pocas las veces que alguien me escribe con algo tal que así: “tú que tienes experiencia escalando equipos técnicos tal vez nos podrías dar algún consejo sobre como escalar, tenemos muchos retos por delante”

La traducción al mundo real suele ser: vamos hasta arriba de trabajo, estamos intentando hacer y vender más de lo que podemos y nos damos cuenta de que la producción es el cuello de botella. La última frase, la de “los retos” suele ser indicativo de que has levantado pasta y has prometido con todas tus fuerzas.

En ese momento el CEO habla con el CTO, normalmente el desarrollador que ha hecho el 50% de todo el código y dice: “vamos a buscar a alguien que haya pasado ya por aquí y que te cuente como tienes que enfocar el tema”. El CTO, que sabe perfectamente el percal que tiene y pasa tres pueblos de perder el tiempo en hablar de sus penurias con un “gurú” en vez de estar atento al último fuego, termina aceptando. Igual que cuando tienes una enfermedad que nadie te cura y pides cita en un profesional del tarot.

Mi respuesta siempre es: no creo que os pueda ayudar. No es falsa modestia, no es de lejos mi especialidad, pero es que vuestro problema es algo que no tiene solución. Se puede hacer mejor o peor, pero en la vida no se puede tener todo:

No puedes ir rápido y que todo vaya como la seda. No existe. Ni en software ni en otra disciplina.

Por suerte o desgracia los equipos de producto son el cuello de botella de la empresa. Son los que tienen que aterrizar y poner a funcionar todas esas ideas felices que se nos ocurren. Y ahí ya no caben estrategias, ni sinergias, ni reuniones de trabajo, ni documentos colaborativos, ni comités, ni cristo que lo fundó, es tu empresa frente a la realidad de la ejecución, las limitaciones del mundo real.

Así que la solución a tu problema no pasa por squads, kanbans, agile, OKRs u otros metodologías: pasa por entender que la realidad es más complicada de lo que crees y puedes hacer menos cosas de las que quieres.

Pasa por entender que cada línea de código que añades necesita alguien de por vida manteniéndola y que una persona puede mantener un máximo de ellas.

Seguramente, cuando hayas entendido que no puedes tener todo y que si quieres hacer mucho el caos va a ser monumental (y vas a tener que aprender a vivir con ello), ya puedas entrar en la siguiente fase que incluye muchas cosas, pero que las más importantes son:

Y en función de si vas por la vía del caos o la vía del orden (“order or progress” dicen los americanos, que saben mucho) estas dos cosas tienen que ser radicalmente diferente. Necesitas gente diferente y procesos diferentes.

Así que el truco es que no hay truco, lo siento. No vale con una conversación de 45 minutos con alguien que “ya lo ha hecho”. Sí que puedes decidir cuanto balanceas y tener expectativas claras de lo que puede pasar, y apechugar. Cuando ya seas una máquina engrasadísima, conozcas el negocio, etc es posible que puedas ir con cierta velocidad y cierto orden. Me imagino.

Dirás, ya pero la empresa X lo hace. Y te respondo con un refrán popular: “en todas las casas cuecen habas”

Odio El Ingles

La primera vez que tuve una reunión en inglés, hace unos 12-13 años, creo que no era capaz de construir una oración de 5 palabras. Entendía a duras penas, especialmente a los británicos. Las pasé putísimas y la sensación de “mejor lo dejo” era diaria. Por suerte había gente en la empresa que se reía de mi con suficiente estilo como para pensar que incluso podría ser divertido. Con los años he mejorado bastante, aún con muchas carencias que suplo con una dosis importante de jeta.

Pero no odio el idioma porque se me de mal (bueno, también), lo odio porque no soy yo el que habla. Es una versión diferente. La forma en la que uso las palabras y como las engrano es lo que hace que sea como soy.

Y no es -solo- por la limitación de vocabulario, mi sensación es que mi parte del cerebro que uso para pensar se malgasta procesando si tengo que decir poner la puta ese de la tercera persona en el verbo o si people es plural o singular.

Pero amigo, el idioma internacional del software es el inglés; programamos en inglés, documentación en inglés, reuniones también en inglés aunque todos habléis castellano (somos la elite, que no se note que somos españoles), hasta las notas las tomo en inglés con tal de no sentirme un fracaso profesional. Incluso escribo en inglés, soy un vendido, un chaquetas.

Uno de mis programadores preferidos es Kenta Cho, no es conocido, ni lo será, me encanta por su estilo diseñando mecánicas de juego super sencillas. El amigo Kenta tuitea en japonés (o eso creo) y programa igual que escribe: pensando en japonés.

Otro buen ejemplo son los rusos, tienen su estilo y estoy seguro que cada país y cultura tiene una forma de atacar los problemas. Y es bastante obvio que la cultura viene dada por el idioma (o al contrario, no soy experto pero me parece una relación suficientemente obvia). No es casualidad que sean los magos del software de alto rendimiento, su tradición matemática seguramente tenga mucho que ver. Además no se cortan ni un pelo, su código suele estar comentado en ruso.

Y así podemos ir cultura por cultura. Pero la situación actual es que todos convergemos: ahora ves presentaciones técnicas de Bytedance (chinos, creadores de Tiktok) y solo sabes que son no americanos por el inglés penoso, si tenían una cultura de desarrollo diferente desde luego ya no está o no la sacan a pasear.

El inglés es el autotune del desarrollo; los matices ya dan igual, todos vamos enfilados por el mismo camino, si había alguna diferencia cultural que hacía que la forma de atacar los problemas o el punto fuerte fuese diferente, tranquilo que ya se difuminará en un inglés mediocre.

Como es lógico, no tiene ningún sentido no saber inglés. Tienes que saberlo, tienes que poder vender lo que haces, pero igual que cuando cambias de provincia se ve una cocina diferente, me encantaría ver lo mismo en el desarrollo de software.

Podrías pensar: Santana es un nacionalista de libro. Nada más lejos de la realidad. Estoy 100% en contra de que la política se apropie la identidad cultural. Estoy a favor de aprovecharla (la identidad, no la política) para buscar formas diferentes de hacer lo mismo. A favor de comunicarlo también para que todo el mundo lo entienda.

Por desgracia en España tenemos muy muy poca tradición tecnológica (en cualquier ámbito) y desarrollar en castellano suena pueblerino, de provincias, poco profesional. Pocos post técnicos son en castellano, igual que pocas charlas de “alto nivel”. Ser nosotros mismos es, en resumen, malo.

Whats Like To Be Good

“I know what’s like to be good” son las palabras que me quedaron grabadas hablando con un advisor de startups, uno de esos que te ayudan a montar parte del equipo, cuando le pregunté cómo podía ayudarnos.

Estos días estoy entrevistando a perfiles diferentes a técnicos. Entrevistar a carabolis es fácil, cuando eres uno de ellos sabes de qué va todo el tinglado. Normalmente con unos minutos te hagas una idea de qué tipo de perfil tiene, donde puede o no cuadrar y en qué cosas se está vendiendo un poco. Somos malos vendiendonos, alguna cosa buena tenía que tener. Nadie te cuenta esto cuando montas una startup.

Ya me sé todo ese tema de que las entrevistas tienen que ser lo más objetivas posible, que tienes que eliminar el “bias” y demás. Nada en contra de que los procesos sean los más objetivos posible, pero la realidad es que nunca lo son, no se puede evaluar una persona objetivamente y mucho menos para algo que dista mucho de ser una cadena de montaje. No es mi intención entrar aquí, así que ahí lo dejo y me voy a lo mio.

Lo que a mi me suele pasar cuando veo un perfil bueno es que mi sexto sentido me avisa. Alguien levanta una banderita en tu cerebro y rara vez falla. Es difícil explicar objetivamente lo que es, pero hay una intuición detrás. Esa intuición de saber “qué significa ser bueno” no viene sola, se genera de años de experiencia trabajando (y contratando) con mucha gente, pasar por diferentes tipos de empresa y entendiendo lo que mueve a cada perfil.

El problema es que cuando entrevistas a alguien que está fuera de tu ámbito estás perdido. El fulano de la banderita está a otras cosas. No sabes diferenciar lo bueno de lo malo, no sabes cuando te la están metiendo doblada o qué detalles son los que van a marcar la diferencia. Cuando pregunto a un programador que me cuente el proyecto más interesante en el que ha trabajado, en medio minuto sabes si cerraba tickets o resolvía problemas. Con alguien de marketing, en ese medio minuto estoy fuera de juego.

Es cierto que hay cosas que son comunes: interés, curiosidad, capacidad de análisis y síntesis, pasión (sí, da gusto ver cuando a alguien le gusta algo) pero no vale con eso.

El caso es que cuando no tienes la intuición solo se me ocurren un par de formas de buscar al perfil adecuado:

1) Ponerte en la piel y entender bien lo que necesitas. Y aquí lo más fácil es hacer lo que se supone que esa persona haría y listo.

Os pongo un ejemplo práctico. Ahora mismo buscamos gente de comercial. Yo no he vendido en mi vida nada ni creo que lo venda, no entiendo nada del proceso de venta (más allá de lo que aprendes viendolo de fuera que te sirve para pegarte el pisto alguna que otra vez). Así que para entender lo que significa estoy haciendo algo típico en ese area: intentar vender a puerta fria.

Cuando monté Tinybird el objetivo era que el logotipo estuviese en la puerta de algún coche de competición. Creo que podemos, aún recuerdo una reunión con Alteryx en uno de los viajes a SF, de cuando se podía viajar, y en la que nos contaban que tenían más bien poco ARR. Hoy están en un coche de F1. Así que me estoy dedicando a intentar vender Tinybird a alguna marca de competición para intentar ahorrarnos pagar una pasta por un logo de tamaño minúsculo en el casco de un piloto. No he conseguido nada como ya imaginabais, pero aprendes que es más difícil de lo que parece. Solo saber a quién y cómo atacar dentro de la organización es absurdamente difícil.

2) La otra forma de generar esa intuición es no generarla y buscar a alguien del que te fíes que sepa distinguir entre el grano y la paja. Las empresas de recruiting en teoría hacen esto. En la práctica rara es la vez que tienen la misma intuición que tú.

Otra opción es buscar a alguien que haya pasado por ese puesto y te ayude a entender a quien entrevistas.

Esta segunda opción suele ser mejor, no tienen incentivo por colocarte a nadie, pero pedir a tus amigos que te entrevisten gente no es bueno para mantener la amistad. Tampoco es perfecto, hay algunas cosas que son difíciles de evaluar desde fuera de la empresa (de ahí también la diferencia de criterios con las agencias de recruiting)

Si no quieres abusar demasiado puedes preguntar sobre qué preguntas hacen en las entrevistas, qué vieron en cierta persona (que también conoces), qué guión siguen, cual son los “red flags”, que valoran muy positivamente, donde es más fácil equivocarse, qué es más difícil de ver, qué pruebas “técnicas” ponen, qué hay que preguntar y en general todos los porqués de lo que acabo de decir, es también una buena forma de hacerse una idea. Es bueno incluso hacer estas mismas preguntas al propio candidato :).

Como siempre, vas a cometer errores contratando, pero las personas no somos máquinas que podamos evaluar al milímetro con preguntas. Lo que sí sé es que cuando los fundadores de una startup no tienen claro para qué quieren contratar un perfil y sólamente lo hacen porque “es lo que toca” (que suele pasar con los VPs), es la receta infalible para el desastre.

Contraintuitivo

Un buen día alguien me dejó unas gafas de ver de lejos. La gilipollez esa que haces cuando eres jóven de “a ver qué tal me quedan”.

Resultó que, lo que estaba lejos, se veía bien, nítido. No tenía ningún sentido, como algo lejano se podía ver bien? claro, estas gafas fuerzan la vista, pero no deben ser buenas a la larga. Eso pensé yo.

Siempre había visto todo borroso, la televisión, las personas, los paisajes. Es lógico, si algo está lejos, se tiene que ver mal. Punto.

Pero aguanta, esto no es lo contraintuitivo.

Pasé toda mi secundaria y bachillerato sin ver nada de lo que el profesor ponía en la pizarra, nos sentaban por apellido, así que siempre me tocaba al fondo. Pedir sentarme más cerca de la pizarra estaba fuera de mis habilidades. Hay cosas que no se solucionan con unas gafas.

Así que desarrollé un sistema para poder coger apuntes: entender lo que decían. No podía permitirme no hacerlo, copiar lo que ponía en la pizarra para entenderlo después era imposible. Como es lógico, la pizarra estaba lejos, mala suerte por apellidarme Santana.

Me crucé un día con mi madre por la calle y no la saludé. Me paró y me dijo: tú, hijo, no ves nada.

La miopía se cura? es lo primero que pregunté al señor de la óptica. Primera gran decepción de mi vida.

Aquello que a priori es una tara, resultó ser una de mis superpoderes en la universidad. La capacidad de atención y concentración que desarrollé aquellos años me permitieron seguir las clases sin problema. Tenía que estudiar relativamente poco (aunque lo hacía todos los santos días) y era sencillo asimilar todo aquello.

Toda esa capacidad se fue perdiendo con los años y sobre todo, cuando contraté la tarifa de datos de mi smartphone.

Me lo escribo para que cuando me encuentre con alguna limitación me acuerde que tal vez sea un regalo del cielo.

El Software Libre Y Las Empresas

Hay dos extremos en el mundo de las empresas y el software libre: las que lo crean y las que lo usan. En el medio hay otras que son las que contribuyen al que crean otras empresas.

Por ejemplo, si miras las contribuciones del kernel de Linux verás empresas como Redhat, IBM, Facebook que contribuen pero no controlan el proyecto. En mi opinión esto es lo que debería pasar siempre, pero claro, no todos los proyectos tienen una fundación detrás, en este caso Linux Foundation, ni tienen tanto impacto, pero hay otras como Apache fundation que gestionan muchísimos proyectos pequeños. Tampoco hay que ser iluso, es importante mirar el “board of directors” y sobre todo en que empresas trabajan.

Luego tienes empresas como Mongo o Elastic, que crean, guían el proyecto y además tienen un negocio que basan en esa pieza de código. Todos sabemos lo que ha pasado en los últimos años con cambios de licencias de software para evitar que el gran Amazon use su software. Redis, Elastic, Mongo, Mapbox han hecho cambios de licencia relativamente duros para evitar que otras empresas aprovechen su trabajo y les hagan la competencia.

Yo que sigo creyendo en toda esa historia del software libre, pienso que hace avanzar a la humanidad, de hecho me parece que hacer software abierto es una “externalidad positiva” de libro, especialmente si lo haces con consistencia y resuelves un problema, por pequeño que sea. El otro día escuchaba un podcast donde el CEO de databricks, empresa que mantiene Spark, comentaba que su producto era usado por las científicas que han hecho posible la vacuna del puto coronavirus. A su vez spark surge como proyecto aplicando el famoso paper de map reduce de google, de cuando google compartía cosas sin ser marketing vacío. Wikipedia usa kafka (creado por Linkedin), entre otros, para velar que su contenido sea independiente, habilitando uno de los mejores proyectos que seguramente veremos en lo que nos quede de vida (y da igual cuando leas esto). Si eso no es hacer mejor el mundo que baje Dios a decirnos qué es.

Pero la triste realidad es que la mayoría de empresas lo único que hacen es usar ese software libre. Unas pocas colaboran un poco, alguna contribución de vez en cuando y ya. No pasa nada, es lo normal, muchas empresas suficienten tienen con lo suyo.

En CARTO, la empresa que era CTO anteriormente, basabamos nuestra tecnología en open source (y el producto en si también es open source). Sin embargo, aunque sabíamos como funcionaba apenas contribuíamos y eso a la larga terminó pasando factura, porque para innovar necesitas no solo saber como funciona si no cambiar lo que necesitas. Y para cambiar necesitas músculo. Así que para paliar este tema contratamos a los mejores del mundo en ese momento y pusimos unos cuantas personas de la empresa a trabajar 100% en eso.

El caso es que me creo bastante que para que una empresa de tecnología sea puntera tiene que conocer tan bien lo que usa como si lo hicieran ellos mismos. Y esto es como plantar un árbol, cuanto antes lo hagas, mejor. No tengo claro que muchas empresas “deep-tech” se den cuenta de esto a tiempo, una empresa tarda unos años en madurar a todos los niveles y unos años en tecnología es la vida. Echa la vista atrás 10 años y verás a lo que me refiero.

Por eso una de las cosas que estamos haciendo en Tinybird es contratar a gente para aportar 100% a Clickhouse, la base de datos que usamos en nuestro producto. La norma dentro de la empresa es, para entender lo que está pasando, se mira el código fuente, lo demás son conjeturas. No solo se trata de contratar gente, se trata de crear el equipo, la cultura y la dinámica que será la semilla para la mantener la parte de innovar viva dentro de unos años. Estas cosas suelen ser caras, pero más caro es quedarme mirando como otros lo hacen por ti.

Por otro lado, me quema la sangre cuando pensamos que aquí no se pueden hacer estas cosas, pero cuando hablas de tecnología puntera todos los españolitos nos cuadremos mirando a San Francisco (aunque el software open source se desarrolla muchas veces el otro lado del planeta). No es que a mi me importen las banderas o fronteras, pero verás, cuando mejor les vaya a tus vecinos, mejor te irá a tí y sus otros vecinos, también. Por suerte este juego no es de suma cero. Cierto es que en hay una parte importante de cultura y que la industria a tu alrededor cuenta, pero ahora estamos en un punto donde tener a ciertos perfiles es “sencillo” y donde la financiación entiende apuestas así.

Echar A Los Leones

Como “manager” soy lamentable. No es falsa modestia, podéis preguntar a cualquier persona que me haya sufrido como jefe. Hacedlo en privado, en público ya sabéis que nadie dice la verdad, no vayamos a quedar mal. No pasa nada, no hay mejor cosa que asumir tus limitaciones y dejarte de gilipolleces de “superar tus miedos” o “dejar tu zona de confort”.

Y soy malo porque, además de tener un nivel de empatía más bien bajo y tampoco me motiva mucho mejorarlo, la gente me aburre. No me aburre en el sentido “soy un ser superior y tu conversación carente de sustancia intelectual es desmotivante”, más bien en el de “me cuesta estar con gente porque tengo que hacer un esfuerzo extra en no parecer tonto”. Esta escena de “Pulp Fiction” define bastante bien mi relación con las interacciones humanas.

El caso es que, por desgracia, en esta vida te toca ser “manager” en alguna ocasión.

-·-

A mi hija, en edad de ir justito para andar, le gusta bajar y subir escaleras. Las baja por el lado donde no está la barandilla, el cerebro humano a veces tiene estas cosas. Me mata tener que cogerla y bajar las escaleras, porque me cuesta creer que nadie nazca para que le guste cargar con un ser de 15 kilogramos arriba y abajo. Mientras llora y te manda en la dirección contraria a la que vas.

Algún día va a hacerlo sola, se va a calzar la hostia del siglo y me tocará llorar. Eso pensé un día hace unos meses en el que, gracias a la entidad superior que controla este tinglado, justo leía esta maravilla, del libro Art & Fear (que parece de arte pero en realidad habla de la vida), que te pego aquí:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity.

It seems that while the “quantity” group was busily churning out piles of work - and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay

Así que me dije, cuantas más escaleras suba y baje, con o sin barandilla, menos probabilidad de que me toque pasar la angustia de esos segundos, que parecen meses de confinamiento, entre que oyes el golpe y empieza a llorar. Y con sinceridad, así me deja un rato tranquilo.

Empecé a dejarla bajar y subir las escaleras. Yo simplemente miraba desde 3 escalones más abajo, para en más de una ocasión cogerla al, literalmente, segundo bote. Meses más tarde me pide que me vaya más abajo, que ella puede sola. Cuando ve las orejas al lobo pone el culo en tierra, porque aprender a usar la barandilla no lo llevamos en los genes, pero lo de ahorrarnos dolor parece que sí. No tengo la certeza de que haya bajado las escaleras ella sola, pero tampoco tengo la duda. Y ese creo que era el objetivo.

-·-

Y me doy cuenta que esa ha sido y es mi estrategia de gestión: echar a los leones tantas veces como sea posible y ver si sobreviven. Cuando sobreviven, y lo hacen la mayoría de las veces, ya no te necesitan, aunque te odien un poco por no haberles ayudado.

Organización de Servicios profesionales

En Tinybird empezamos al revés que muchas empresas de producto: por la parte de monetizar. Antes de meternos 100% a desarrollar producto y luego ir viendo (pivotar lo llaman) decidimos empezar facturando con un producto muy pequeño y haciendo servicios profesionales.

El tema de servicios profesionales es un tema un pelín tabú, ya sabes, la métrica estrella de cualquier SaaS B2B es el MRR (la gallina que entra de forma recurrente al mes) y claro, los servicios profesionales no son, en teoría, recurrentes y tampoco escalan bien. Bien en el sentido de que necesitan personas, y somos caros y tenemos sentimientos, cosa que una máquina en amazon no. Por suerte nuestros clientes son personas y prefieren a alguien humano del otro lado.

Pero la realidad es que la mayoría de productos tienen una parte de servicios profesionales y son necesarios para cerrar clientes que paguen pasta. Hay muchas razones, la más importante es que hemos idealizado tanto las empresas de producto, gracias a esos blog post de americanos vendiendonos el mejor humo, que hemos perdido el norte y nos hemos pasado de vendernos a nosotros mismos.

Pero el troleo, que de verdad me apetece, no es para este post, ahora vengo a hablar de como organizamos internamente la gestión de estos servicios. Sí, es un post sin historia, símplemente te explico aquí lo que hacemos por si te sirve de algo en tu empresa. También lo escribo para mi yo pasado (y futuro, como todo lo que uno escribe), me hubiese gustado que alguien me explicase esto hace 10 años.

Somos una empresa remota, así que todo el proceso intenta ser lo más asíncrono posible. Sería gilipollas si dijese que es 100% asíncrono, pero sin duda molaría mucho más. Por otro lado, toda la gente en servicios profesionales son desarrolladores, nada de “perfiles más baratos”, “más de negocio” o “recursos intercambiables”.

Ahí va, tenemos:

Estas reuniones la mayor parte de las veces son de coordinación técnica-negocio, es decir, siempre hay cosas que hay que negociar, decisiones que pueden afectar para cerrar un cliente, quizá hay que dar un toque a alguno para ver qué tal lo llevan…

Si hay algo que necesita tiempo especial hacemos reunión específica sobre ello previa actualización en su correspondiente proyecto.

Nada nuevo bajo el sol, seguramente la mayor parte de empresas de consultoría tengan un proceso mucho más depurado y haya herramientas maravillosas para este tema, pero la clave está en no olvidar que los servicios profesionales en empresas de producto también necesitan organización y procesos, especialmente 100% remoto.

Tinybird, resumen del año

Casi ya poniendo la guinda al año es un buen momento para parar a recapitular. Y no hay mejor forma de reflexionar y ordenar tu cabeza sobre algo que escribiéndolo. La madre de dios, ni un post sin aroma a Coelho en este blog.

Si llegas aquí sin saber que es Tinybird, es una empresa que fundamos hace un año y pico en la que hacemos un producto que permite analizar cantidades ingentes de datos en tiempo real. Échate un ojo a estos posts que escribí hace tiempo

En los anteriores posts hablaba de tecnología, aquí voy a cambiar el tercio, vamos creciendo y aunque la tecnología sigue siendo ciudadano de primera, hay otras cosas destacables importantes.

Al tajo.

No hemos casi cambiado el stack, prácticamente usamos lo mismo pero estamos haciendo una cosa que normalmente hacen empresas mucho más maduras: refinar. Nuestro stack es sencillo al máximo y eso hace que en vez de hablar de tecnología, hablamos de cómo solucionar problemas con tecnología.

Cuando haces un producto y la gente empieza a usarlo, por muy bueno que seas (incluso les pasa a los norteamericanos) hace aguas. Y lo hace porque los usuarios se meten por caminos que no esperas. Y está pero que muy bien, no hay nada más sencillo a nivel de producto que resolver donde tus clientes tienen problemas porque es precisamente para lo que arrancas tu proyecto,

Hemos subido un escalón. Hemos atacado proyectos de los de quedarse hasta las 3 de la mañana que nos han hecho mejorar. No estoy orgulloso de quedarme hasta las 3 de la mañana, es un error y es síntoma de no saber hacer algo, pero es también el reflejo de que la cosa no era fácil. Si procesar 12 trillones de filas en un solo día no es el siguiente escalón ya no sé qué será.

Hemos crecido el equipo en la primera mitad del año contratando a gente clave y sobre todo, vamos acompañando con procesos y formas que son de empresa mucho más madura. Seguramente el ser 100% remoto hace que sea prácticamente obligatorio, pero que sea la segunda o tercera vez que lo hacemos tenga algo que ver, aunque siempre haces cosas fatal. Seguramente explique en un post las cosas que estamos haciendo diferentes sobre procesos.

Seguimos siendo poquitos (11 según escribo esto) manteniendo la eficiencia. Esto ha pasado en parte porque levantamos el pie al ver el tema del puto virus y por otra porque hemos preferido poner bien el cimiento. La prueba del algodón: podemos dejar un proyecto o feature en manos de cualquier persona del equipo y lo va a sacar adelante con nota.

Además he estado probando alguna nueva forma de contratar y de llegar al público objetivo: streams en twitch hablando de temas técnicos, explicando ofertas de trabajo, haciendo ofertas un poco diferentes…

No hemos hecho ruido (o eso creo). Salir en el periódico, ganar premios y demás está muy bien, te sube la moral, eres el jefe, “putos amos son esta gente”, pero no da de comer ni hace que tu producto sea mejor.

En vez de eso, foco en los clientes: responder rápido, meternos hasta la cocina en sus problemas, entender bien lo que duele. Esta frase también la podría soltar cualquier consultora internacional pero yo no llevo corbata y me puedes preguntar el modelo de datos de cada cliente.

Foco en que el producto sea útil y rápido. En aumentar el ingreso recurrente y la facturación.

Foco en que la gente del equipo vaya cogiendo las partes del negocio fundamentales con onboardings, videos, cursos, trabajo en común y machacar todos los santos días con lo mismo.

Hemos agachado las orejas cuando la hemos liado parda, que ha sido unas cuantas veces.

Cerramos un año bastante bueno a todos los niveles, aunque como siempre miramos mucho más a donde no hemos llegado que a lo que hemos conseguido.

Otra forma de contratar

Mira que me había prometido que no volvería a hablar de cómo contratar pero pensaba que no estaba de más explicar cómo lo hemos hecho esta última vez. Y soy gilipollas porque cuando hice aquella promesa fue porque me dieron por todos los costados (no sé si con razón o no, compruebalo tú misma), y yo soy una persona sensible, me afecta cuando me sacuden.

En general si lees posts de como contratar que hay por ahí terminarás por: 1) contratar a la misma gente que contratan el resto (que puede ser bueno o no) y 2) montando un arco de iglesia tremendo que muy seguramente no necesites para contratar. Estas dos cosas también son aplicables al resto de cosas y así ves empresas con kubernetes y 154 microservicios para aguantar una carga que no despeinaría una raspberri pi alimentada por energía solar.

Y después del anterior párrafo que me podría haber ahorrado, pero que me apetecía meter, pasa que cada empresa y cada momento necesita contratar de una forma (en mi opinión, claro). Y el momento para Tinybird es el de una empresa de 10 personas donde todo el mundo hace casi de todo y que sobretodo, las personas que entren ahora formarán los pilares culturales y serán las referencias de los que vengan detrás de ellas. Si en una casa haces mal un tabique se arregla y punto, si pones mal un cimiento no te imaginas como acaba la historia.

Hasta ahora habíamos tirado de personas cercanas, es decir, personas que eran y siguen siendo para nosotros referencias. Esta es la opción fácil y la mejor al arrancar, pero claro, tiene un problemón: no sales de tu círculo, es más difícil que nadie te venga a decir “pero qué estáis haciendo pin-pin-es” y terminas haciendo todo igual que lo hiciste en el pasado.

Así que en las siguientes contrataciones nos planteamos hacerlas con gente de fuera de nuestros círculos, gente que no conociesemos. Es fácil, es seguir el pesadísimo flujo habitual: sacas una oferta, esperas que llegue gente, los entrevistas y haces una oferta si todo va bien. Sin embargo hay una cosa que valoramos y es que la gente tenga interés por lo que hacemos y no por quienes somos.

Halaga una barbaridad que publiques una oferta de trabajo y te lleguen personas que quieren trabajar contigo símplemente por ser tú, pero la realidad del invento es que tú te conoces mejor que ellos y sabes que el personaje de internet no dice nada del como será el trabajo. Así que para conseguir personas realmente interesadas publiqué un tweet preguntando si la prueba técnica que pedíamos para una supuesta oferta laboral era complicada o no.

Recibí buen feedback de la oferta, pero ese no era el objetivo. Hubo gente que le interesó y se molestó en buscar lo que hacíamos, si buscábamos gente y enviar un correo preguntando. No hay nada mejor que la gente que pregunta (de hecho el test técnico es de preguntar más que de resolver) porque son los que realmente están interesados. Porque ojo, estar interesado en hacer kubernetes con microservicios y loquesea es faćil porque es lo que te dicen en hackernews, pero meterte en una empresa donde se dedican a crear APIs que atacan a billones de registros con tiempos de respuesta de menos de unos pocos cientos de milisegundos no es lo que se ve todos los días.

El resultado ha sido muy bueno: el interés y la calidad de las personas que se han presentado al puesto de backend que buscabamos ha sido altísima y solo nos ha llevado 1 mes cerrar el puesto con muy poco tiempo invertido. Esto parece una payasada que suelto para que la historia termine bien, pero es importantísimo para una empresa que los fundadores puedan ver a los candidatos, ahora, si lleva mucho tiempo al final delegarás eso (y puede que con 50 personas tengas que hacerlo, pero no con 10) porque es un verdadero tostón.

YesCode

El otro día Elon Musk tuiteaba esto (es interesante leer las respuestas, sobre todo las suyas)

No es que Elon sea el más coherente tuiteando ni el que más me guste, pero hay que reconocer que el amigo ha creado algo que hará cambiar industrias completas, que hará que nuestra prole quiera aprender machine learning, física, aeronáutica y otras tantas cosas que estaban dadas por hechas, en vez de ser tiktokeros. No tengo nada en contra de los tiktokteros pero el beneficio de un tiktoktero no es compuesto y sinceramente, no hay tanto espacio para hacer sketchs de especial de nochevieja continuamente.

Me despisto, el caso es que es el CEO de una gran compañía hablando de Inteligencia Artificial con criterio, es decir, sabe qué está diciendo, no son palabras vacías escritas por un comité de discursos para tranquilizar a tu accionariado haciendo ver que estás a la última cuando tu capitalización bursátil se va al garete. Repito, Elon no es el CEO típico y no creo que sea ejemplo de muchas cosas, pero sabe de que habla y pone dinero en ello (porque en software también es cosa de echarle dinero).

Cuando hablamos de transformación digital no tengo muy claro lo que quiere decir, pero creo que se parece mucho más a seguir haciendo lo mismo pero siendo “más digitales”. Cuando yo leo transformación digital lo que pienso es una reestructuración completa de, empezando por el CEO, con un enfoque pensado desde la tecnología. Pero esto, como sabemos es algo casi imposible y seguramente las empresas que hoy nacen digitales serán los nuevos bancos, los nuevos fabricantes de coches, etc.

Sabes que voy a contar una historia, así que no lo demoremos: hace un tiempo tuve la oportunidad de hablar durante un buen rato con el CEO de una empresa top del IBEX35. Yo no soy muy listo pero lo suficiente para saber que cuando yo estaba yendo, él ya había ido y venido media docena de veces. De hecho me quedé impresionado del conocimiento técnico que tenía. La pregunta entonces es, si hay personas tan capaces en puestos muy influyentes, por qué las empresas Españolas, por poner un ejemplo, no terminan de pasar de usar tecnología a ser tecnológicas? la razón -que escribo aquí como si estuviese totalmente seguro de que es así- es que ser alguien sobresaliente no es suficiente, además tienes que entender bien la tecnología (y además todo ese rollo de tener suerte, claro). No me refiero a poder hablar con alguien de tecnología, quiero decir, entender con profundidad la tecnología, tenerla interiorizada. Además, saber de negocio, marketing y otras cosas imprescindibles que todos los libros de emprender describen perfectamente.

Vamos a ilustrar esto con una anécdota, como hace la gente que escribe libros de cientos de páginas. Hace 5 años el CTO, entonces, de Tesla da una charla magistral, no solo por el contenido, si no por saber condensar y explicar la estrategia tecnológica de la empresa de forma tan clara (después de verla piensa si serías capaz de hacer lo mismo con la tuya). Hay una parte de la charla que dice (extracto de los subtítulos de youtube, editado por mi para que se entienda todo a mi favor, si quieres verlo, en vez de leerlo, el extracto empieza aquí):

We've worked with several other make a automotive oems with both Daimler and Toyota and others and it's really fascinating trying to interact with them especially around software electronics because there's a huge fear they just don't totally trust it they don't totally understand it and they kind of treat it like this thing that's to be contained and managed very carefully
There's one story I remember where we had a motor that was controlled by software and there was a concern, what if the motor goes too far [...] what if it over drives in one direction or the other direction, how are we ever gonna prevent that.
We said well can't you know we should just make sure the software doesn't do that and we'll put the appropriate checks and the software and you know write it very carefully and test it.
They said no, you know we can't ever be sure the software will work so they actually put a mechanical bracket around the motor so that they didn't have to care about the software. [...] to me that's kind of just this totally different approach you know if you can't trust the software and you just say you're not even gonna try and make it correct and then put a bunch of mechanical stuff around it you know it's it's a different mindset.

La mejor parte es justo antes de empezar a contar la historia, donde explica el porqué ellos apuestan por el software y dice “this was possible because of the culture of the company”. Eso es, no puede ser de otra manera.

Y para poner la guinda a la historia, sabéis que venía de hacer el menda en cuestión? pues una modificación de un porsche para convertirlo en eléctrico (con un rango de 44km) en 2002. Por favor, si vas a dedicar 2 minutos, que sea a ver como era el prototipo en vez de terminar de leer este post. Es un clarísimo ejemplo de la eficiencia de lo cutre

El problema es que la tendencia actual es ir al extremo opuesto, cuanto menos tengas que saber de programar y de tecnología, mejor. Usemos herramientas “No Code” o “Low Code” (en las que en realidad inviertes tu tiempo en aprender un pseudo lenguaje de programación propietario en vez de invertirlo en aprender algo standard, abierto y que durará más allá de la quiebra de la empresa “no code”), no importa el modo mientras lleguemos al destino, aunque hayamos quemado todos los puentes por el camino. Estas herramientas, los cursos de 3 meses y demás familia tienen su sentido, son muy útiles, pero no creo que nos podamos conformar con ello. No creo que todo el mundo en Tesla sepa como ajustar los parámetros de una red neuronal, pero necesitamos gente que imprima cultura de la tecnología y esa por suerte o desgracia se aprender con esfuerzo y trabajo. Lo peor es que las barreras de entrada en muchas ocasiones las ponemos la propia gente que trabajamos en tecnología, sobre complicando y haciendo tecnología por la mera tecnología.

Aprende a programar, aunque sea un poco.

(Contratar a) la persona correcta

La vida es un conjunto de sube y bajas, algunos baches por el camino -que a veces son pozos- prioridades cambiantes y donde casi todo lo que hacemos viene motivado por una cosa fundamental: las personas que están a nuestro lado.

Puede que sea de forma más o menos egoista, de forma directa o indirecta, da igual que el gobierno sea de derechas o de izquierdas, seas alto o bajo, lista o tonto.

Estos dos párrafos que me acabo de marcar bien podría haberlos escrito Coelho, pero este post en realidad va de contratar gente. A lo mejor podría dedicarme a escribir libros de filosofía “Coelhiana” startrupera, pero podría confundir al público y pensar que no trabajo de verdad. En este blog se escribe sobre lo real.

Hace unos años, cuando empecé a liderar procesos de selección y marcar la estrategia, mi foco era en la excelencia técnica. No quiere decir ni que estuviera equivocado ni que ese fuese mi único objetivo, pero sí era un valor fundamental. De hecho escribí un post sobre como consideraba que había que hacerlo -por el que la policía de internet me lapidó- y del que ya solo estoy en algunas cosas de acuerdo.

Desde aquello han pasado unos años, algunas empresas y un par de historias (las buenas historias siempre vienen de dos en dos) que han cambiado mi forma de mirar las cosas.

Y además te las voy a contar, y lo sabes.

Hace ya siglos en la empresa que trabajaba estábamos en un proceso de “due diligence” típico y parte de ese proceso fue hacer pruebas técnicas a todo el equipo de tecnología. Las pruebas no eran sencillas, eran las típicas pruebas de puzzles y programación de pizarra, que son tan absurdas como inútiles, y que lo único que hacen es aumentar el ego del entrevistador, de hecho un día haré un post sobre cual es mi prueba ideal, pero no nos despistemos ahora.

Al terminar nos dijeron que las pruebas eran horribles (usaría palabras más contundentes pero luego me tachan de negativo), cosa que ya sabíamos después de las pestes que echábamos cuando salíamos de las pruebas (no lo voy a suavizar: pensábamos que eran gilipollas). Pero, vamos a ver, cómo es posible que fuésemos capaces de hacer lo que hacíamos y las pruebas técnicas fuesen tan malas. La explicación era bastante sencilla, estaban evaluando al equipo por separado y no como un equipo. Subestimaban el efecto pegamento del equipo.

La segunda historia es bastante más reciente. Si no lo sabes, te lo digo yo, al entrar en un corporate en un determinado puesto lo primero que hacen es asignarte gente. Es decir, no la buscas tú, estas empresas tienen mucha gente y siempre hay gente que termina proyectos o quiere cambiar de equipo. Montar un equipo y hacerlo funcionar es sencillo, eso lo hace cualquiera, pero coger gente de diferentes equipos, que tú no eliges, y hacerlo funcionar es harina de otro costal.

Así que mi estrategia de solo trabajar con gente “excelente” técnicamente se derrumbó. Entonces recordé la primera historia: si en aquella empresa éramos unos paquetes técnicamente pero luego éramos capaces de producir cosas bastante decentes, tal vez lo de ser excelente pese muchísimo menos a la tener un equipo cohesionado.

Así que manos a la obra me puse a hacer algo que nada tiene que ver con la tecnología: crear buen ambiente, esto es, hacer de ese grupo de personas un equipo haciendo que el ambiente de trabajo fuese bueno, donde hubiese comunicación. Dicho de otro modo, que el buen trabajo fuese el resultado de que la gente se llevase bien.

Entró gente al equipo rechazados de otras áreas, contratamos gente que no pasaba el baremo técnico establecido por el área, hicimos cambios de gente que parecían absurdos, también di la oportunidad de cambiar de equipo a quien no estaban de acuerdo con la forma de trabajar. El resultado, después de 6 meses, fue que el equipo producía, se ayudaban pero sobretodo entendían la situación y necesidades de los demás.

Así que ahora, cuando hago una entrevista, rara vez pregunto algo técnico (aunque el perfil sea puramente técnico) y busco cualidades personales (dentro de lo que mi incapacidad social me permite) que me hagan ver que la persona es de esas que van a tender la mano cuando otra esté en pozo.

Lógicamente tener conocimientos técnicos es muy importante, pero es mejor trabajar con alguien con quien puedes aprender lo que no sabes a con alguien al que miras mientras trabaja.

La Nueva Normalidad

Llevo jugando a simuladores de carreras unos 3 años, me lo tomo bastante en serio dentro de que es un juego, le dedico unas 3-4 horas semanales. Creedme, una carrera de una hora exige una concentración que te deja exhausto. Pero no dejes de leer, esto no va de juegos ni de carreras.

Al principio me apuntaba a carreras con gente que encontraba por internet, simplemente gente que pasaba por allí y quería jugar. Era sencillísimo ganar, simplemente había que esperar a que se salieran de la pista (la mayoría son chavales de 20 años sin cabeza)

Luego pasé a competir en carreras más oficiales con reglas más serias y mejores pilotos, esa gente ya no estaba por estar, le gustaba correr. Pero pasado un tiempo estaba codeandome con los mejores. La sensación era la de ser el “jefazo del volante”.

Pero entonces me apunté a una competición donde había profesionales y pase de estar en top 10 a estar en top 100 (con suerte). Ya no era tan jefazo, de hecho no tenía ni idea de por donde iban el resto para marcar esos tiempos.

La realidad es que entre los mejores y yo solo hay un 1-2% en los tiempos de vuelta. Es decir, como en todo, la calidad no es lineal, llegado un punto para mejorar un 0.1% tienes que invertir 10x en tiempo y esfuerzo.

Para ponerlo en contexto, los mejores hacen 50 milésimas más rápido que yo cada curva. 50 milésimas en 20 curvas que tiene un circuito hace 1 segundo por vuelta que al final de una carrera es una diferencia de 1 minuto. Es decir, la calidad viene de muchos pequeños matices que hasta que no entrenas una y otra vez no eres capaz ni de apreciar.

Repito, la diferencia entre alguien que hace un trabajo de calidad y otro que no, está en detalles que no vas a llegar a apreciar nunca. De hecho, la mayoría de esas veces, esos detalles vienen de conocer y aplicar los fundamentos de lo que estás haciendo.

Al competir con los mejores empecé a hacer las cosas que hacen los mejores, cosas que sin haber estado ahí no se me hubiesen ni pasado por la cabeza: aprovechar ese centímetro de piano, sobrevirar un poco en ciertas curvas para sacar esa décima y otras tantas. Sé que para estar a un nivel que no dé pena en la competición tengo que hacer todo eso, es el mínimo.

Al cabo de meses, vuelves a correr con los que corrías al principio y te da cuenta que, sin ser muy consciente, estás en otro nivel. Tu nueva normalidad es mucho mejor, pero es tu nuevo normal.

Por eso cuando dudas a veces es bueno coger un poco de perspectiva, mirar a los lados y ver si estás o no con los mejores.

Este post también se puede puede resumir en una frase que un día me dijo un buen amigo: nunca vayas a un pueblo peor que el tuyo.

Tecnologia Tinybird

Hace unos meses escribí un post sobre las decisiones que tomamos en tinybird en tecnlogía, este la continuación (y espero ir actualizándolo cada 6 meses). Pero un par de notas antes de empezar.

Para mi producto y tecnología son exactamente la misma cosa. Mejor dicho, forman un conjunto que no tiene sentido separar en una primera fase. Para bien o para mal decisiones que se toman en un sitio afectan a otros en formas totalmente inesperadas. Mejor asumirlo desde el principio y tener en cuenta que no todas las decisiones técnicas son puramente técnicas. Solo el que hace tecnología por la tecnología puede hacerlo así.

En tecnología ya solo hacer que las cosas funcionen es complicado. Nosotros hemos elegido un stack de tecnologías “conservador” porque queremos que las cosas funcionen. No nos movemos por lo que hagan otras empresas, hacemos las cosas porque pensamos que es lo correcto para la nuestra.

De las cosas fundamentales nada ha cambiado especialmente, y esto es de lo mejor que podía pasar.

Seguimos usando solo dos lenguajes backend (python y C++) y javascript en el frontend. Buena decisión que tenemos que mantener. Para algunas cosas python no es lo mejor, C++ no es lo más rápido de desarrollar pero ningún lenguaje es perfecto.

Hemos añadido una pieza grande más al stack de desarrollo: ansible. Por alguna razón, viendo ansible, y habiendo visto chef, algo me dice que el mundo del aprovisionamiento está un pelín roto. Seguramente porque cada proveedor de cloud ha tirado por su lado y que docker nos ha llevado unos 15 años atrás. Pero ansible era sencillo, basado en python y sobre todo, tiene la mayoría de recetas que necesitamos (más en el siguiente punto)

Hemos complicado la arquitectura un poco. En realidad es bastante. Hemos tenido que atacar algunos proyectos en los que necesitabamos escalar bastante y eso requiere más piezas. Los sistemas distribuídos incrementan la complejidad órdenes de magnitud.

Así que ahora tenemos nginx para balancear, redis para la persistencia (con su sentinel), zookeeper para coodinación de replicación y varnish para balanceo y cache (que no usamos ahora mismo). Y clickhouse para almacenar datos, claro.

Pensarás, si usas nginx para qué varnish? bien, conocemos muy bien varnish y nos permite balancear exactamente como queremos (el balanceo de carga lo hacemos en base al análisis del SQL y de los datos en cada máquina para aprovechar localidad de datos y caché, esto daría para otro post). Usamos nginx casi exclusivamente por https, esa es la realidad.

La persistencia que hacemos es un poco diferente a lo habitual. Usamos redis para guardar los datos fundamentales de los usuarios en un formato lo más eficiente para consulta y trabajo desde aplicación (el formato en el que guardamos mapea al modelo de datos de consumición en python) en vez de usar un modelo relacional puro. En clickhouse guardamos todo el histórico de operaciones (un kafka pero a la inversa, para los milenials). Dicho de otro modo, si queremos hacer una consulta sobre lo que ha pasado o hacer analítica vamos a clickhouse. Si vamos a responder una petición de API sobre cuantos datasources tienes vamos a redis (la mayor parte de veces no tocas ni redis).

Ya sea en redis o clickhouse todo tiene esquema. Cuando modelas una aplicación tienes dos momentos de elegir el esquema: cuando guardas o cuando lees los datos. La segunda es como estudiar el día antes del exámen, es mejor ir haciendo el trabajo poco a poco.

La razón de hacer esto así en vez de usar una sola base de datos con todo es: rendimiento y sobre todo poder usar nuestro producto para construir nuestro producto. Toda la analítica que sacamos del propio uso de la plataforma la hacemos con la propia plataforma (de hecho exponemos al usuario parte de esas tablas internas). Podrás pensar que dedicar tiempo al rendimiento es absurdo en una empresa que está validando su modelo, pero tenemos algunos SLA que nos exigen estar por debajo de tiempos de respuesta y aquí necesitas ser rápido y predecible.

Hemos además dividido algunas partes de la aplicación en varios procesos. Fundamentalmente es una decisión para que los despliegues en alta disponibilidad sean más sencillos pero en desarrollo todo sigue siendo un solo proceso maravilloso. Este arranca threads y otros procesos, pero no tienes que gestionar comunicación ni procesos ni todo el cristo de docker-compose punto yamol. En desarrollo no necesitas ni nginx, ni varnish ni flatuas.

Gitlab es una autentica joya. Seguimos usándolo para absolutamente toda la automatización y rara vez nos ha dejado tirados. Además no dependes necesariamente de ellos porque tienes sus “runners” que permiten ejecutar todo en local así que puedes seguir desplegando aunque esté caído. El balance es muy bueno entre el servicio y la autonomía. Es un lujo depender de una sola herramienta para todo el desarrollo. Cada día me gusta más la estrategia que tienen como producto.

Por otro lado durante estos meses hemos encontrado esos problemas que te hacen ver que estás en producción y que cuando están arreglados hacen de un producto un buen producto. El típico fuego que no sabes de donde viene, no entiendes y termina siendo un bug que metiste por algo inesperado.

El numero de bugs registrados ha crecido a más de 100. Hay una categoría especialmente importante que es la de “PAIN”. Hay veces en las que hay pequeñas cosas, que por pequeñas parecen poco importantes, pero que son los que por aculumación terminan por hacer de un producto algo mediocre. Intentamos atacar esos primero, pero lo cierto es que, como siempre, tenemos mucho más trabajo del que podemos atacar.

Durante estos meses también hemos estado desarrollando proyectos. Muchas veces para salir del paso se desarrollan pequeñas herramientas que terminan siendo clave en el producto. No hay nada mejor que lo que desarrollas del fruto de la pura necesidad.

El código por otro lado empieza a tener partes complejas. No solo porque intrinsicamente lo sean, que también, si no porque al ir añadiendo funcionalidad o resolviendo casos extremos generas complejidad. El mayor error de los equipos de desarrollo es no asumir que hay cosas complejas. En vez de asumirlo y tratar de documentarlo, explicarlo y hacer que la gente invierta tiempo en entenderlo, tratan de refactorizar para simplificar sin tener en cuenta que ni lo conocen, ni pueden eliminar la complejidad intrínseca ni que van a añadir otra complejidad diferente.

Hay cosas que son muy importantes que no hemos tenido tiempo de atacar, por ejemplo, casi no hemos contribuído a clickhouse (la base de datos que usamos por debajo), apenas unos commits sueltos.

En resumen, a pesar de intentar mantener todo lo más sencillo posible, hay complejidad que no puedes evitar. Aún somos capaces de gestionar todo entre 3 personas (2 backend + 1 frontend) con consultoría de por medio.

La semana que viene entra la primera persona que contratamos al equipo de desarrollo. Aquí viene el siguiente reto, sobre todo porque es 100% remoto por razones más que obvias (estamos en medio de la cuarentena, por si lees esto en un futuro) y es la primera persona que entra sin haber estado desde el día 0.

Bola Extra

El equipo de Tinybird llevamos ya unos años haciendo aplicaciones de alto rendimiento. El chat de Tuenti, una portada de Google (el making of ), el mapa de la portada del WSJ cuando Obama ganó sus segundas elecciones, gestionado un cluster de cientos de máquinas sirviendo en tiempo real y un largo etcétera.

Durante estos años hemos ido aprendiendo, la mayor parte de veces a base de prueba y error, investigar como funciona el software y hardware y como interactuar con ellos. Nunca habíamos recopilado toda esa información, simplemente era conocimiento que estaba repartido en notas, presentaciones y obviamente nuestras cabezas.

Así que hemos decido crear “principios de analítica en tiempo real para grandes cantidades de datos” un curso que explica, siguiendo nuestros principios de entender como funcionan las cosas, como hacer analítica en tiempo real con grandes cantidades de datos explicado desde las bases.

El curso estaba pensando para hacerlo en persona (de hecho era el onboarding de nuestro primer empleado) pero dadas las circunstancias lo vamos a hacer, resumido, online. Es un curso de fundamentos, no está relacionado con ninguna tecnología concreta. Si explicas las bases con lógica y de manera sencilla, aplicarlo a tu día a día, da igual que uses una base de datos u otra, es trivial.

Lee toda la información y apúntate gratis -hagamos la cuarentena un poco más llevadera- por aquí: Principles of real time analytics on large datasets

Siguiente Decada

No me creo las predicciones, no funcionan. Hay que ser muy chulo para pensar que puedes adivinar el futuro, pero el proceso de pensar qué podría ser importante en el futuro basado en lo que conoces es bastante interesante.

Por otro lado, hacer predicciones es un plan perfecto: si aciertas siempre puedes recuperar tu predicción en el futuro y ponerte la medalla, si no, pues nadie se acordará de tu predicción pero mientras las haces das el pego.

Bueno, al grano: creo que será la década de los límites.

Estamos llegando al límite de emisión de CO2, todos pensabamos que el petroleo se acabaría, pero no, resulta que antes de eso habría tanta carbonilla en el aire que no podríamos ver la luz del sol (y si vives en Madrid seguramente ya te sepas lo de respirar). Bueno, lo ha matado el calentamiento global y que la industria del automóvil ha tocado techo y toca renovar. Qué mejor para un gobierno que toda una industria se renueve. Yo compré acciones de Tesla hace unos meses y guardo a buen recaudo mi seis cilindros en linea porque en 10 años ya dudo que las empresas de coches quieran perder reputación construyendo coches deportivos.

Aprovechando la excusa del CO2 parece que veremos un movimiento (que ya ha empezado agitado por las agencias de marketing) a favor de la sostenibilidad. La realidad es que el ahorro y aprovechamiento siempre ha sido eficiente en términos económicos, otra cosa es que hayamos valorado más la efectividad.

Esto, unido a que estamos llegando al final de la ley de Moore es muy posible que empecemos a ver hardware específico para ciertas cosas. Ya existen GPUs, TPUs (y ya existían DSPs), es posible que veamos hardware específico para tareas web (más allá de balanceadores) y bases de datos (lo mismo volvemos a los mainframes)

Eso o hacemos que los desarrolladores mejoren un orden de magnitud, cosa que no parece que vaya a pasar, seguimos con una demanda altísima de técnicos y eso hace que no sea posible una formación tan profunda como para hacer que seamos realmente buenos.

No obstante, los desarrolladores podemos hacer cientos de cosas para mejorar las emisiones de CO2, echad un ojo a este artículo (del 2015), la lista de ideas es tan larga como interesante.

Otro límite que vamos a tocar es el del vandalismo, por decirlo suave, de los datos. Los grandes han estado haciendo lo que les ha dado la real gana con nuestros datos y es posible que lo sigan haciendo una temporada, el problema es cuando tienes tanto poder que superas al de un gobierno. Europa ya ha ido dando cera a las grandes (con multas irrisorias y unas leyes cosméticas) y en el otro lado ya empezaron hace unos meses con Mark dando explicaciones y siguen ahora. El juicio de Microsoft e internet explorer se va a quedar en anécdota.

Las empresas tendremos que dar cuentas algún día de los datos que usamos, igual que informamos a haciendo de como usamos el dinero. Habrá facturas pero de datos?

En tecnología: todo igual.

Empresas buscarán desarrolladores de React para mantener todo el legacy. Esas mismas estarán negociando los contratos millonarios contratos con Amazon (al estilo oracle) y anunciarán a bombo y platillo como han apagado la última máquina de EC2.

Se buscarán ingenieros que sepan como usar EC2, lo más probable es que la siguiente remesa de desarrolladores ya solo conozcan entornos basados en kubernetes o similar, empujados por, de nuevo, las grandes para que vayas hacia unos sistemas complejísimos que solo alguien con muchos recursos puede gestionar.

Espero ver más herramientas verticales para desarrolladores. SAP es un ejemplo, pero espero que se parezcan más a unity, la verdad. Más lenguajes especializados(de forma que gente menos técnica pueda acceder a usarlo) y que cubran todo el ciclo para llevar productos a producción (herramientas de desarrollo y debugging, dependencias, publicación y monitorización).

Me encantaría ver como es la década de la estandarización en el software, que el software permite integrarse bien, correr en cualquier sitio y que el vendor lock-in sea algo que haya que buscar en la wikipedia.

Veremos blogposts de empresas explicando que dejaron la nube porque no era rentable y seguramente veremos renacer el onpremise y la nube privada. Espero que veamos más gente haciendo nuevos servidores y sistemas operativos (estoy últimamente viendo el movimiento de los unikernel).

Miles de desarrolladores ruby estarán continuamente excusandose para no parecer que están totalmente fuera de juego. Para entender como será puedes ver a los desarrolladores de java hoy.

El único software que seguirá funcionando será el creado en C/C++, como siempre. Las únicas web que seguirán funcionando serán las creadas en 1990 con HTML básico.

Es posible que en unos años el hype sobre la IA pase y empecemos a verla aplicada en tareas que de verdad importan en vez de optimizar al milímetro sin un mínimo de humanidad. Me creo la IA que es capaz de ayudar al humano no a reemplazarlo, ayudando a entender qué le pasa a un paciente, qué problema tiene un coche, hacer que los formularios web no me pidan 50 campos y me entiendan como si estuviese dando mis datos a una persona. fast.ai creo que está acertando en esa línea, intentando que los que saben del dominio a mejorar sean capaces de usar IA en vez de ser reemplazados por modelos creados por gente que no tiene ni zorra de lo que está modelando.

No veremos coches conduciendo solos, la legislación va demasiado lenta para cambiar en solo 10 años. FYI, hay tractores autónomos en producción hace más de 15 años, aún la legislación los prohíbe en la mayoría de países. Mi única esperanza es que eliminen los coches de las ciudades, mejoren la red de autobuses de forma que sea algo intermedio entre un autobús y un cabify/uber y dejen la autoconducción para carreteras y autovías, más sencilla y donde más eficiencia y beneficio podemos obtener.

Miles de bebés dirán sus primera palabras: “Alexa” y “Siri”

Será también la década de lo distribuído: redes sociales, dinero y trabajo (si yo tuviese dinero invertiría en empresas que hagan herramientas para gestionar el trabajo en remoto). Ojalá el protocolo bittorrent sea un redescubrimiento (o IPFS, o lo que sea, me da igual). Espero que sea la década de la vuelta a las provincias.

Y espero que sea la década que recordemos como la tecnología ayudó a mejorar la salud, que ayude a entender y prevenir lo que hoy no podemos ni entender ni curar y que en 2120 puedan contar cosas como esta.

En el 2030 escribiré (con vim, claro) otro post analizando si acerté o no.

Una Decada

En 2010 empezaba a venir por Madrid a algunas conferencias, la mayoría de ellas eran sobre Rails, el framework web que ya no mola, que por aquel entonces estaban empezando a despuntar (gracias a aquel maravilloso video-demo de DHH del que tenemos tanto que aprender). En aquel entonces fue un soplo de aire fresco, gente que le gustaba lo que hacía, que compartía sin pensar en el retorno, lejos de la casta y lo rancio del desarrollo que había visto hasta esos días. Me empezaban a conocer por el “fulano de los tractores”.

Escribía por aquel entonces en un blog de blogger que había sido comprado por google (me sorprende que no lo hayan cerrado) mi post preferido, hacía algunas demos que me llevarían a trabajar para Vizzuality, después CartoDB, más tarde CARTO. Aún recuerdo perfectamente el momento en el que empecé a trabajar con la gente de Vizzuality, iba a trabajar 2 meses (el contrato era temporal, no se fiaban, con toda la razón) con los mejores de la escena en aquel momento, subir a primera división.

Lo que se llevaba eran nubes de tags, wordpress tunedos, RT manuales, gente hablando de la nube (no ha cambiado esto mucho), startups ofreciendo cosas gratis y nosotros preguntándonos como iban a ganar dinero, hoy ya lo sabemos.

Di alguna de las que serían mis primeras charlas (y creo que las mejores)

Hice lo que creo que ha sido mi mejor trabajo hasta la fecha.

Más tarde dejaba CARTO, pasaba sin pena ni gloria por un banco, vendía agroguía y empezaba Tinybird.

Qué es lo que ha pasado en estos años?

Lo moderno hace 10 años es legacy hoy: Node.js era una plataforma inestable y los más modernos defendían a muerte el paradigma asíncrono (los más viejos ya nos habíamos leído la Beej’s guide 10 años antes) con benchmarks vacíos. Hoy todo ha evolucionado y hasta IBM hace librerías para node.js. Programar en rails es de viejos (que ahora ganan dinero).

El frontend ha explotado: hace 10 años se concatenaban ficheros javascript y hoy hay una docena de herramientas para hacer “bundles”. El desarrollo frontend está más cerca de ser visual basic y está haciendo que la ley de Moore se nos quede corta.

El open source ha pasado a ser una herramienta de marketing. Se acabo la ingenuidad del desarrollador que ponía su trabajo a disposición de los demás por el mero hecho de compartir.

El desarrollador ha pasado a ser ciudadano de primera, se acabó la tiranía de la corbata que han pasado de reirse a tener miedo. Todo el mundo recuerda los sueldos desorbitados de tuenti, hoy hordas de gente no técnica hace cursos comprimidos en 3 meses para sere “developers”. No sé si esto es nuevo, las consultoras daban formación de J2EE hace 15 años a filólogos, pero desde luego el status social es bien diferente. Ahora programar es cool, quien lo iba a decir.

El vendor lock-in ha pasado de ser algo a evitar a estar orgulloso y procamarlo a los 4 vientos. Veremos la siguiente década las quejas de desarrolladores migrando sistemas imposibles de mover fuera de amazon.

Microsoft ha pasado a ser el bueno de la película y a meter Linux dentro de Windows.

Volvemos a repetir la historia. El navegador es la nueva máquina virtual de java, si no leed la descripción de WebAssembly y decidme si no os resulta familiar.

Lo que antes llamaban data mining ahora se llama data science/data engineering y en teoría ha pasado a reemplazar el instinto por un puñado de modelos y a ajustar al céntimo sin un mínimo de humanidad. A mi me gusta llamarlo “optimizar sin escrúpulos”.

Las conferencias técnicas han pasado de ser un medio a un fin.

Dos cosas han venido a cambiar como hacemos hoy las cosas: deep learning y blockchain. Si bitorrent hubiese aparecido en esta década y el protocolo fuese basado en JSON (en vez de un formato eficiente) es posible que hubiese sido otro de esos grandes avances.

Linux ha pasado a ser el dueño del escritorio (en tu android, eso sí)

Los formularios de las webs siguen sin entender a los humanos.

Los sistemas operativos siguen sin resolver la ejecución de aplicaciones distribuídas (de mientras amazon nos vende lambda, un CGI venido a más).

Puedes aprender a hacer cualquier cosa en Youtube, web de universidades y similares. Si ahora tuviese 20 años menos es muy posible que no hubiese hecho una carrera universitaria.

Ha sido la década en la que internet se ha hecho capitalista y a pesar de ello sigue siendo maravillosa.

En tecnología, la década ha sido brutal pero esta charla, que tiene más de filosófico que de técnico, en la que explica el porqué no podemos seguir por el camino actual en cuanto al desarrollo se refiere, no deja de resonarme y espero que esta década sea cuando reencaminemos.

Licencias Software

Hace unos meses me escribe de una empresa para echarles un cable para entender si Clickhouse tenía sentido en su plataforma. Para los que no me hayáis escuchado hablar de Clickhouse (y es raro) es una base de datos analítica, no muy conocida, que tiene la mejor tecnología de datos que he visto en años, desarrollada por Yandex, el Google ruso (y este dato es importante para el devenir del post)

Los rusos son gente hecha de otra pasta a nivel de desarrollo. Mi impresión es que son así de bestias por su formación matemática heredada de la cultura que se forjó en la unión soviética (*) (a la fuerza, pero no entraremos en el cómo). Y este párrafo es pura percepción personal probablemente influída porque últimamente hablo con algunos rusos muy listos, pero seguramente sean tan buenos como los españoles :)

Si echas un ojo al software que usamos todos los días hay algo ruso de por medio. Usas postgres? algunos índices están hechos por rusos, nginx? Creado por un ruso, usas Google? El algoritmo de indexación lo creo un tal Sergey Brin… coge cualquier gran proyecto open source, mira las contribuciones y siempre hay rusos. Compáralo con las españolas (teniendo en cuenta que Rusia tiene 3x población)

Al tema, esta empresa de la que no diré el nombre, pero con un equipo técnico de los más interesantes del panorama startup español, baraja resolver el problema con Clickhouse (entre otros) con un criterio exclusivamente técnico: buscan arreglar el problema con la mejor solución. Pero a la semana del primer correo me escriben de nuevo diciéndome que algunos de sus clientes les habían comentado que usar Clickhouse es un “no” por ser ruso (también hablaban de software chino) y por tanto su proyecto tendría que ir por otro camino con la consecuente consternación del equipo.

No soy abogado y seguro que tienen razones legales o de cualquier otro tipo buenísimas para hacer eso, pero también sé que esos clientes deberían buscar asesoría técnica inmediatamente.

Lo habitual es que cuando tienes una empresa de VC detrás estén muy preocupados por un “exit”. Una de las cosas que podría joder un “exit” es la propiedad intelectual del código, imaginate que has usado código de vaya usted a saber quien y cuando vendes tu empresa reclamen su parte, por eso una de las cosas fundamentales que miran es si tu código usa librerias con licencias virales (cómo GPL) o restrictivas. O incluso uses código sin licencia de un menda de GitHub (ahora entenderás el porqué mucha gente pide en tantos repos poner la licencia). Aquí hay una lista de cosas que un VC suele mirar en una due diligence

Pero no veo que “liability” podría causar un software, código abierto, con licencia Apache 2 por mucho que detrás esté Yandex. Detrás de todo gran producto open source hay una gran empresa. De hecho el modelo mongo o elastic es mucho más peligroso ya que son empresas con grandes cantidades de dinero VC que viven exclusivamente de ese software (al contrario que Yandex), y ya sabéis, cuando empiezan a apretar las ganas de ganar dinero el VC ya no es tan divertido y a veces se estira demasiado la cuerda (que se lo digan a meetup.com)

Pero cabría la posibilidad de que estos rusos metieran, ordenados por su gobierno, unos caballos de Troya en su código. Podría, pero la historia reciente nos dice que es más fácil que llegue por un módulo npm o un ataque dirigido (que se lo digan a Everis) y que no hace falta que sean rusos. Podría ser un “huawei” pero no, el código está disponible y no hay un control global, no hablamos de un despliegue para analizar datos en la NSA (he estado leyendo a Snowden últimamente)

Aún me pregunto qué puede pasar por la cabeza de esa gente. A mí me daría mucho más miedo pensar que mi startup tenga los passwords en 1password después de la ronda de $200M a que parte de su stack sea un software open source, escrito por unos rusos brillantes fuera de la politica de la gran empresa donde fue creado (si no es imposible que hubiesen construido algo de tanta calidad). O quizá me preocuparía más que tengan que ir a por una solución cloud, de peor calidad (**) por la cual quizá tengan que doblegar en unos años (que se lo digan a los bancos con HP, IBM u Oracle)

Me desmotiva mucho cuando el dinero puede a la razón. Tal vez en este caso estas empresas tengan poderosas razones pero solo se me ocurre algo tan oscuro que pueda entrometerse en estos temas: la política, empresas del gobierno y al hilo por la “opinión pública”. Como en cualquier tema últimamente puede mucho más la información superficial, posiblemente hidratada con algún que otro bulo, que la capacidad para buscar fuentes de información veraces y con criterio. Si alguien dice que el software ruso es malo, lo será.

Por mi parte seguiré usando software ruso, chino (mirad la lista de contribuciones a tensorflow) o español, si hay una cosa bonita en el software es que nos pone a todos al mismo nivel, no importa si es alemán, español o ruso, escrito por un hombre o una mujer, un alto o un bajo, lo instalas porque te funciona y resuelve un problema.

Bonus track

Estos días estoy escuchando el podcast de inteligencia artificial de Lex Fridman, el amigo no es el más dicharachero, pero las conversaciones son interesantes. Concretamente me ha encantando la primera media hora de conversación sobre lenguajes de programación con Jeremy Howard, fundador de fast.ai

(*) echa un ojo a la lista de matemáticos rusos Especial mención a la cantidad de mujeres en la lista.

(**) Clickhouse está fácilmente 3-4 años por delante de cualquier tecnología cloud hasta que llegue lo nuevo de Google, Procella.

Los Fundamentos

Día a día nos pasamos en la oficina de Tinybird (amablemente proporcionada por Google Campus) discutiendo sobre cachés, índices de base de datos, optimización de lectura en función de la compresión, como funcionaría el sistema en distribuído en función de que datos… nos gusta entender como funciona incluso aunque no sea totalmente necesario.

El 99% de negocios les importa poco ese tipo de cosas, y así está bien, con saber que instalando el framework y usando su API lo tienes solucionado o usando la receta es muchísimo más que suficiente. Hay cientos de miles de negocios que no saben lo que corre por debajo de lo que usan y así debe ser. A nadie se le ocurre tener que saber como funciona un coche para poder conducirlo. De hecho la humanidad no avanzaría si esto no fuese así, nos basamos en el conocimiento que otros ya concentraron.

Pero eso no evita que no tengamos que volver a los fundamentos de vez en cuando. El otro día di un taller de fundamentos de visualización de datos. Mucha gente al principio esperaba empezar a usar “ponga aquí su herramienta” pero no. El curso era de cuales son los conceptos básicos de percepción humana para entender como representar los datos. Por ejemplo, saber que un pie chart es una aberración en la mayoría de casos se entiende perfectamente explicando las bases y 2 ejemplos.

La diferencia entre enseñar a hacer visualización de datos y enseñar los fundamentos es como dar el pescado o enseñar a pescar. Aprender a aplicar los conceptos requiere tiempo, repensar mil veces, equivocarse otras tantas hasta que eres capaz de interiorizarlos y de asentarlos en base a sacar la esencia de cada ejemplo.

Pero no creo que nadie pueda hacer nada realmente bien sin entender las bases. Nadie puede hacer bien ML sin entender las matemáticas que lo fundamentan, no se puede conducir bien sin conocer principios de física de un coche y no se puede hacer bien una query a la base de datos sin saber como funciona por debajo. El problema es que es mucho más sencillo y da más beneficio usar las recetas que en la mayoría de veces funcionan. No habéis visto esos departamentos de marketing ó desarrollo haciendo todo exactamente como viene en el manual sin pensar realmente lo que están haciendo?

Así que cada vez que veo alguien que se entretiene en mirar qué hay debajo, especialmente en el mundo del desarrollo, me da una señal de que esa persona posiblemente sea una buena candidata a ser unos de esas soñados “10x”, de las que en un momento de los delicados te va a sacar del agujero, de las que saben que siempre hay una buena solución (y saben el porqué a veces hay que escoger la mala)

Nunca en mi vida me he arrepentido de haber invertido tiempo en entender como funciona algo, de hecho es posiblemente las mejores inversiones a largo plazo que he hecho. No hay que ser un 10x para hacerlo, ni si lo haces no te convierte en superhéroe, pero necesitamos gente que lo haga.

Bonus track

Relacionado con lo anterior esta charla donde explica como muchas de las cosas que damos por asumidas sobre el rendimiento del hardware actual, no son ciertas y solo basta con mirar lo que hay debajo. En esa línea el famoso You are doing it wrong del creador de Varnish.

El Complejo Del Corporate

He sido muy muy crítico con el corporate durante mi vida profesional, lo sigo siendo, pero últimamente al mismo tiempo trato de entender el porqué están donde están. Después de todo no se consigue facturar cientos o miles de millones de un día para otro por un golpe de suerte.

El corporate sigue teniendo cosas malas no, malísimas: software de pésima calidad (la mayor parte de veces externalizadas) miles de personas que no saben nada y a las que lo de la transformación digital les suena a chino los cuales están normalmente “amparados” por convenios laborales (a pesar de ello bajo ningún concepto eliminaría). Desde el lado startup es lo único que se ve y la razón por la que se menosprecia a la gran empresa.

Pero ojo, Facebook, amazon o cualquier otra empresa gigante (bueno, y cualquier startup de 200 personas) son tan corporate como el más corporate español. No nos engañemos, tienen la ventaja de 20 años menos de legacy, pero los problemas convergen cuando hay muchas personas haciendo lo mismo.

Pero no he venido aquí a hablar de lo que todos ya nos hemos quejado, quiero hablar de esa gente que son los que sacan adelante el trabajo, los que, a pesar de miles de reuniones absurdas son capaces de crear software y hacer esa herramienta que todo el mundo usa y que todo el mundo quiere sustituir por “lo nuevo”.

No hay vez que hable con alguien que trabaje en un corporate español que no te cuenten la historia de un proyecto increíble, que todo el mundo usa pero del que no se habla con orgullo, siempre son “unos cuantos scripts ahí corriendo”. Y aquí es donde fallamos, esos “scripts” que dan servicio a miles o a veces millones de personas son el comienzo de algo. Pero nos quedamos ahí, en cuanto tenemos una solución que funciona tendemos a pensar que es mala. Y lo siguiente es pensar en mantenerla ahí y luego ya haremos el megaproyecto que lo haga “bien”. Esos megaproyectos casi nunca salen bien y finalmente se termina haciendo otra solución que tampoco cumple para no quedar mal. No nos damos cuenta que no es posible hacer algo “bien” sin tener experiencia previa?

Echad un ojo a la historia de React y veréis que empezó como “unos Javascript para resolver una parte”. Pero no se quedaron ahí, avanzaron, lo dieron cariño y han hecho de React un standard. Es un caso especial, pero fijaos en los miles de ejemplos que estos neo-corporates sacan todos los años, dan charlas sobre ellos… ahora, cuantas charlas habéis visto de “"”ponga aquí tu corporate favorito español”””, creéis que son tontos y no son capaces de hacer nada decente, o que realmente falta ese empujón para creerse que haces algo bueno, digno de ser expuesto (y de paso mejorar la empresa en todos los sentidos)

Como en la mayoría de cosas en la vida la perseverancia es lo que hace a algo ser bueno, necesitamos ese cambio cultural que haga que dejemos de pensar en que las cosas son para salir del paso y pensemos que el dorado llegará y pensemos que el dorado se construye, que esa gente que ha construído esa solución que te ha sacado del apuro seguramente haya aprendido y pueda iterar. Y cuando termine la siguiente iteración pueda iterar de nuevo y tal vez generalizar y seguramente empezar a hablar de ello públicamente.

Como Elegimos La Tecnologia Tinybird

Creo mucho en que la mayoría de empresas de tecnología deberían empezar con un servidor de 30€ al mes, con un stack basado en PHP (o unos ficheros HTML y algo como firebase) y en el que el equipo técnico, trabajando mano a mano con negocio, vaya editando directamente en producción hasta tener market fit. Rompe absolutamente todas las buenas prácticas, pero es interesante recordar dos cosas:

1) Tarde o temprano tirarás el primer código (así que cuanto antes mejor)

2) Lo que importa es validar que el negocio tiene sentido no que eres el que mejor arquitectura tienes. Un buen técnico se define también por saber cuando NO invertir tiempo en algo.

Así que todo lo que diga en las siguientes líneas cógelo con pinzas porque ni yo sigo mis propios consejos.

La tecnología acompaña a la empresa

La mayoría de las decisiones tecnológicas que hemos y estamos tomando vienen dadas por la experiencia en CARTO, sobretodo la última fase que viví que fue el cambio hacia B2B. Así que, dado que Tinybird es una herramienta también 100% B2B, de bajo nivel (plataforma) y orientada a trabajar con datos hay una serie de cosas que tuvimos en cuenta antes de arrancar(*):

Algunas de las decisiones

Aquí algunas de las decisiones, sin un orden muy definido, la mayoría de ellas bastante dogmáticas.

Nada de servicios externos. El onpremise es algo que va contra el “sentido común” de un producto SaaS pero a veces ciertas empresas no quieren (o pueden) sacar datos de sus servidores. Y Tinybird es una herramienta que en muchos casos tiene que vivir cerca del origen de los datos. Piensa en tinybird como un nitro para tu base de datos actual, así que tiene que colocarse allí donde haya que acelerar. Esto nos da una ventaja competitiva con respecto a Big Query o Redshift (además de otras muchas que iré comentando en siguientes entregas)

No usamos ni un solo servicio externo, todo funciona en un portátil sin conexión a internet. De hecho una cosa que te permite no depender de servicios de amazon/google/azure es que puedes montar tu producto sobre hardware de verdad. Otro ejemplo de esto es Algolia que decidió usar servidores “de verdad” y aquí explica muy bien las razones. De hecho el poder hacer esto añade una capa de seguridad (nosotros separamos los datos de los clientes de forma física) también muy bien acogida por el corporate. Y obviamente todo mucho más barato que en la nube.

Tenemos que empezar a perder el miedo a explicar que debajo de nuestros servicios hay servidores y recursos finitos cuando los servicios son basados en recursos.

Lo más sencillo posible: relacionado con el anterior, nada de kubernetes nada de miles de servicios. No significa que en la parte SaaS no podamos usarlos, pero evitándolos siempre que se pueda. La aplicación tiene el código para el aprovisionamiento, deployment, tareas como backups y mantenimiento y toda la parte de frontend.

Obviamente solo un repo (salvo una extensión que haremos open source), no creo que tenga sentido tener más de un repo salvo que casos muy específicos, al final tener diferentes repos, aunque suena muy bien, se convierte en un problema de gestión añadido y de integridad de tu sistema.

Todo concentrado en gitlab: repo, tickets, CI, testing. La documentación es el mismo repo. También tenemos el CRM y el blog en gitlab.

Número de dependencias mínimo, es preferible invertir 2 días de trabajo y saber lo que está pasando a usar la dependencia que encuentras en github. Solo usamos dependencias que o bien conocemos o bien hay poco riesgo de que sean un problema por no conocerlas. Se pide perdón cuando haces un commit con una dependencia nueva.

Ahora mismo la aplicación se instala con pip install tinybird.whl y se ejecuta con un tinybird_server. No necesita balanceador, es un solo proceso corriendo en la máquina, punto. Obviamente tenemos un balanceador para tener alta disponibilidad, pero no sería necesario.

Tampoco usamos base de datos al uso, el volumen de usuarios que esperamos no es algo, así que usamos un sistema basado 100% en memoria y almacenamos los datos o bien en disco o en redis (si hay HA). Para la parte analítica guardamos todos los eventos que se producen en la aplicación (obviamente en clickhouse para analizarlo con nuestro propio producto) De esta forma cumplimos con todos las requisitos de trazabilidad que suele requerir el corporate.

Y obviamente esto incluye dejar fuera a los frameworks y toolkits. Usamos las partes que nos interesan de tornado (un framework web muy sencillo) y React. Es cierto que el onboarding técnico se hace difícil encontrar gente, pero es que somos nosotros los que hacemos el framework, nuestro target son precisamente perfiles que les guste saber lo que hay por debajo del framework.

Por otro lado, en mi opinión los equipos de tecnología no escalan bien, este producto está pensado para tener un nucleo de personas muy pequeño (como, en realidad, casi todas las empresas, aunque no lo sepan) y tener los complementos orbitando (tanto en equipo como en tecnología)

La velocidad es clave, así que usamos C++ para las partes críticas (por ejemplo, la construcción de árbol de dependencias SQL o el parsing de CSV) y python para la capa de gestión y partes no tan críticas. Me asombra como la mayoría de las empresas pasan la velocidad por alto pero fijaos en trello, figma o notion

Al hilo de lo anterior y de que teníamos que partir de tecnología existente para acelerar el producto, usamos Clickhouse (una maravilla de la ingeniería). Como ya tenemos una edad para tirarse a la piscina sin mirar si tiene agua, antes de usarla me pegué 1 año estudiando como funcionaba, haciendo pruebas de concepto, probando si era viable contribuir al código, hablando con los desarrolladores y echandoles un cable con el diseño de la parte geospacial. Además, antes de arrancar monté unas charlas y asistí a otras tantas relacionadas con datos para ver como estaba el sector.

El testing: el máximo end to end posible y usando doctest para partes unitarias. Muchas veces la aproximación es prototipo con test mínimos, prueba y luego desarrollo de tests. Por otro lado invertimos más tiempo de testing en lo que consideramos que tiene más valor.

Insistimos mucho en metricar y tener las partes críticas bien medidas. Cuesta poco y así probamos nuestra propia plataforma.

Luego hay otros temas como por ejemplo, no tenemos sistema de usuarios interno, siendo realistas, te ahorras un dolor tremendo en la gestión de usuarios y cualquier empresa va a quererlo integrado con su sistema de autenticación. Quieres además estar integrado con su sistema para eliminar barreras a que más usuarios usen la plataforma.

En general intentamos entender bien lo que usamos, que además sea lo más robusto/probado posible, simplificar todo lo que se puede (teniendo en cuenta que un sistema de datos de por si es complejo) y mantener la burocracia en mínimos pero no tan mínimos que no permita escalar el equipo.

(*) el primer commit es de Febrero de 2018

Fyre Festival

El otro día veía Fyre en Netflix, un documental sobre un festival de música muy bien vendido pero muy mal ejecutado que resultó ser un desastre.

A medida que van pasando las entrevistas a la gente involucrada tenía una sensación familiar, la típica de “estoy metido en un agujero del que sé que no se sale”. Los que trabajamos haciendo en vez de pensando en hacer sabemos perfectamente de qéé hablo. Tenemos ese sexto sentido de “esto no se puede hacer” que a veces nos falla pero cuando da fuerte de verdad, lo sabes.

En mi vida he estado en algunas de esas, pero recuerdo dos, una de ellas hace 15 años donde un lunático pensó que se podía hacer un sistema de domótica en un par de semanas y todos fuimos arrastrados allí. La segunda, de la cual fui además parte de los iluminados que vendían el sueño (y posiblemente el más culpable porque sabía que no era posible), fue en CARTO cuando decidimos que en 6 meses se podría reimplementar el 80% de los construído en años y además añadir más features.

Esto no es un consejo para todo el mundo, pero si volviese atrás, en las dos ocasiones, me hubiese ido de la empresa. Aún sufro consecuencias del peaje que pagué por aquello, en ningún caso me ha merecido la pena, ni he aprendido nada (bueno, aprendí que nunca más lo volverás a hacer) y no guardo ni un solo buen recuerdo. Y lo peor, de largo, arrastré a personas al lodazal.

Afortunadamente teníamos un equipo que supo sacar aquello con unos cuantos meses de trabajo (los que hubiese costado en realidad hacerlo) y mucho esfuerzo. Hay veces que lo de tener un equipo que no te mereces es literal.

En el documental se ve como muchos profesionales abandonan el barco cuando vieron el percal.

Lo triste es que el mundo de software está aún poco profesionalizado y sigue pasando, pero imagino que llegará el día donde los técnicos de este sector seamos capaces de argumentar con algo diferente a rabietas.

Esta semana

Esta semana he terminado mi serie sobre el Data Lake. El Data Lake es algo así como el Fyre festival de los datos, suena perfecto, pero es un trabajo de años, para el que necesitas una cultura de empresa MUY técnica y que incluso así es complicado.

Lo he escrito más pensando en ser una guía para aquellos que estén pensando en centralizar todos los datos que piensen el arco de iglesia que van a montar y si de verdad les da beneficio.

Siempre he pensado que la única forma de aislar lo suficiente a zonas de una empresa es productizar y eso incluye el acceso a los datos. Y dar acceso a Tablau desde fuera de tu equipo/departamento/area a tu base de datos interna no es productizar ni democratizar el acceso a datos, es buscar dependecias externas que limitarán tu avance.

Por aquí la penúltima entrega, las conclusiones y el índice en formato micro libro

Bonus track

Posiblemente ni te interesen los coches ni la mecánica, pero me gustaría que pudiesemos hablar de tecnología con la pasíón que este hombre habla del primer coche tracción delantera que bajó de 9 segundos en el cuarto de milla (un coche de calle potente tarda entre 15 y 17 segundos en hacer 402m)

Tener claro lo que se quiere conseguir, mostrar sin tapujos qué decisiones se tomaron para resolver un problema en vez de darle a la palanca del marketing y tapar lo que realmente es interesante (en el video la limitación del data logger), hablar de los problemas que encontraron por el camino (la suspensión delantera), los problemas que no resolvieron (las roturas de la transmisión en la salida), etc, etc. son las cosas que me gustaría ver en nuestro día a día.

Todo el canal de este señor es brutal si te gustan los coches.

Data lake (y VIII): Conclusiones

Si has llegado hasta aquí y has leído todos los capítulos verás que el Data Lake es el sueño de cualquier empresa media grande. Un sitio centralizado donde se puede consumir de forma uniforme toda la información del sistema.

Bien, es tan soñado que es una utopía si tu empresa no ha arrancado así desde cero (y si tiene cierto éxito, creeme, empezará a haber ramificaciones de los datos por aquello de la agilidad)

Así que si estás planteandote el data lake, data warehouse o sistema centralizado, piensa muy mucho si lo que realmente quieres es que las diferentes áreas de negocio expongan sus datos de una forma lógica.

Cada día más se habla de los microservicios, de dividir las empresas en diferentes áreas para darles agilidad (esto no es nuevo, ya lo decía Ricardo Semler en Maverick), de productizar esas áreas, pero la realidad es que poco se aplica cuando se habla de los datos, donde la centralización es el santo grial, especialmente en empresas donde la estrategia de datos ha sido mover CSV de FTP en FTP y donde básicamente se invierten cientos de millones en mega estructuras que nunca llegan a funcionar porque, ni son ágiles, ni son rápidas, ni son útiles porque se pensó más en la fiscalización que en la disponibilidad de la información y porque hay empresas que saben vender muy bien el dorado cuando el problema que no resuelven es el de las personas.

Hay muchas más estrategías además de centralizar:

Recuerda, tener centralizada la información es el camino, pero el objetivo es hacer que la información esté disponible y a eso se puede llegar por muchos caminos.

Y por último, empieza por la cultura y no por la tecnología, si tus empleados no saben nada de datos (formatos, como se almacenan, distribuyen, consumen…) y no hay unas guías clarísimas que pasen de generación en generación (eso es la cultura, no?) cualquier iniciativa será en vano y terminarán usando la tecnología que se lo ponga más fácil (en este caso en la nube) y lo peor, seguirá habiendo los silos generados para mantener un puesto de trabajo.

Data lake VII: datos derivados

No olvidemos que el objetivo final del data lake es poner a disposición de quien necesite la información de la forma que necesitan consumirla. Es decir, todo lo que he escrito anteiormente no deja de ser grasa, lo importante es poner a disposición la información

Y esto tiene muchos planos, por un lado el que información se necesita, normalmente derivada de la intersección de varias fuentes de datos, y otra el como: a veces se necesita información en tiempo real, otra un sistema analítico para poder hacer descubrimiento, otro se analítica y a veces simplemente se necesita poder exportar a un formato específico (por ejemplo, Excel)

Es decir, tiene que tener la capacidad de transformar y mezclar datos si no que además tiene que soportar cargas de consumo de diverso índole.

Por poner un ejemplo, querríamos disponer de información para servir la analítica de una parte de nuestro negocio en tiempo real (con requerimientos de baja latencia y mucha velocidad) y a su vez tener esos mismos datos disponibles para que un data scientist haga queries muy pesadas para entender y modelar el dataset.

Y claro, que un tipo de carga no afecte a la otra. Y que además este actualizada en tiempo real con nuestro sistema productivo.

Así que, de una y otra forma estamos pidiendo que el data lake sea capaz de ser tan bueno como postgres en carga transaccional, tan bueno como spark para hacer análisis en batch, tan rápido como hbase y siendo capaces de tener capacidades de analítica en tiempo real como kx o Clickhouse.

Y obviamente esto es imposible de tener al mismo tiempo, de ahí que tengamos que replicar los datos.

En general, los casos de uso que debería ser capaz de sustentar son:

  1. Capacidad analítica: es decir, permitir usar BI, herramientas internas, excel o similar para entender los datos

  2. Capacidad analítica++, es decir, permitir casos de uso más avanzados que permitan a gente con más conocimiento técnico usar sus herramientas (jupyter/python, R)

  3. Alimentar sistemas transaccionales. Es decir, una parte del negocio necesita datos de otra parte? el sistema debería ser capaz de poner en su base de datos (mysql por ejemplo) esos datos

  4. Exponer los datos como API. Este es el caso ideal en vez del anterior porque permite a cualquier sistema beber de los datos, independientemente de su naturaleza.

  5. Enviarlos a sistemas variados, S3, FTP, herramientas SaaS…

Y aquí puedes imaginar todo lo que se te ocurra.

Tinybird

Cuando hablamos con alguien con cierta experiencia en el mundillo startup y nos pregunta, después de un rato de conversación “bueno, pero qué queréis conseguir con Tinybird”. Hay muchas posibles respuestas standard en el mundillo en el que nos movemos: “venderla”, “hacer de ella un unicornio” o cualquier empresarial-motivacional.

Pero la cara se les arruga cuando dices: lo que queremos es trabajar juntos de la forma que mejor sabemos, hacer algo que las empresas necesiten, crear un negocio sostenible, con una buena base tecnológica que aporte valor y como resultado ganar dinero. Lo que viene después, como en el 100% de las empresas, nadie lo sabe por mucho que nos empeñemos en buscar fórmulas e indicadores para argumentar lo que básicamente viene a ser una apuesta (un muy bien artículo relacionado sobre la inversión).

Quizá deberíamos entrenar el pitch de vamos a liderar el sector de vaya usted a saber pero no hacen falta grandilocuencias ni adornos artificiales para hacer un buen producto.

Al grano, qué leches hacéis en Tinybird? hacemos dos cosas, un producto y el complemento que casi cualquier producto necesita:

El porqué

Por suerte el sector de la tecnología lleva unos años en la gloria a nadie se le escapa que se puede vivir bien si estás dentro del mundillo y no falta trabajo. Esto es, puedes, ahora mismo, trabajar en una empresa con todas las comodidades, un buen sueldo, sin realmente matarte a trabajar y con retos intelectuales interesantes. Es el escenario soñado.

Y así estaba yo, en un corporate, con ciertos privilegios y con una cómoda jornada de 9 a 5. Quien es el iluminado que me manda a mi dejar ese status quo para meterme en camisas de once varas, no me jodas.

Tiene una explicación sencilla. Hay dos cosas que valoro por encima de los privilegios y el dinero: hacer las cosas como yo quiero y poder trabajar con la gente con la que comparto algo más que oficina. Y esto lo he aprendido a base de confundirme unas cuantas veces y darme cuenta que no todo el mundo está hecho para según que sitios.

Dicho esto, nada tengo en contra de los trabajos 9-5 y ni el corporate (no siempre ha sido así) donde he aprendido muchísimo en un año, sobretodo a respetar ciertas cosas que son difíciles de ver pero que los mantienen vivos y coleando (esto lo dejo para otro post)

Volvamos al qué

Por otro lado tengo en mucha consideración a las personas que aprovechan lo que saben hacer bien, y creo que uno de mis fuertes es hacer sistemas que saben hacer bien la digestión de los datos… puede que llevar 10 años haciendolo tenga que ver. Me mataría dejar de hacer algo con lo que he disfrutado y disfruto.

Qué mejor manera de aprovechar lo que sabemos que haciendo un producto que resuelva algunos de los dolores que hemos pasado durante los últimos años y que vemos todos los días en empresas que trabajan de una forma u otra con datos.

Resolver un problema bien, usando la que consideramos la mejor tecnología para hacerlo, haciendolo con un standard alto de calidad y seriedad, guiado por la necesidad de resolver ciertos problemas y provechando al máximo el conocimiento acumulado gestionando datos en empresas por las que hemos pasado. Y además, hacer todo esto siendo lo más feliz posible y divirtiendose con cada milisegundo que optimizas extrayendo información de los datos. Eso es Tinybird.

Y esto requiere una cantidad de trabajo y esfuerzo que a medida que te haces mayor cuesta hacer. Sí, cuesta trabajo, en mi caso sacrifico horas de otras cosas que me gustan, pero hacer las cosas como crees que hay que hacerlas tiene este tipo de cosas. Sarna con gusto no pica dicen en mi pueblo.

Bola extra: hablando de gente que hace las cosas bien

Al hilo del comentario anterior sobre la gente que sabe hacer las cosas bien y las aprovecha, estoy siguiendo muy de cerca la creación del Instituo Tramontana, especialmente el programa en dirección de producto que imparten dos buenos amigos.

Pero no es solo el contenido del programa, es todo lo que está alrededor del curso, el espacio la solemnidad del programa, las referencias a libros y contenidos con tantos años como calidad (uno de mis propósitos de este año era no leer libros con menos de 30 años, que como todo propósito, he incumplido) y la dedicación con la que están preparando todo. Os recomiendo seguir la lista de correo de Javier, el directo del instituto, donde va contando algunas cosas relacionadas y otras que no, pero que dan contexto.

Las Matematicas

Tengo un recuerdo agridulce de los problemas de matemáticas de la escuela: todo lo sencillo que parecía cuando veías a la profesora resolverlo paso a paso pasaba a ser un mar de dudas cuando te enfrentabas al problema tu solo.

Añadía más frustración el pensar que lo habías entendido perfectamente.

Lo que no sabias era que la profesora había hecho miles de veces problemas como ese, tanto que podía hacerlos mientras los explicaba.

Cuando leo un blogpost sobre cómo la empresa X resolvió Y, ya sea usando microservicios, tal base de datos o cuál metodología, y que además el problema se igual parecido al mío, me pregunto si no será mi profesora de matemáticas convertida en desarrolladora. Me pregunto si no será mucho más complicado y no habrán pasado miles de veces por ahí. Y entonces me pregunto si yo tengo tiempo de pasar miles de veces por ahí.

Por otro lado no hay cosa más divertida que enfrentarte a algo nuevo, es realmente la única forma de entender algo que ya has entendido.

La charla de la semana

En este mundo donde las conferencias se han covertido en en fin (y no como resultado de hacerlo bien) para conseguir leads, en donde la calidad brilla por su ausencia, donde un título “catchy” vale más que plasmar años de trabajo en una charla, da gusto encontrarse con maravillas como esta. Y me ha gustado por varios motivos:

No hay mes que no piense en organizar una pequeña conferencia donde la gente venga a contar la verdad del día a día sin miedos, a explicar cómo hacen esto o aquello, o como resolvieron lo de más allá usando el hack más absurdo.

John Carmack

No es noticia que Carmack es uno de mis programadores favoritos. Gracias a él aprendí muchísimo leyendo el código de Quake (especialmente el 2), escuchando sus maravillosas master class en las quakecon y leyendo maravillas como esta, cuando se fue una semana aislado a aprender machine learning. La forma en la que “locuta” me hipnotiza.

Hace pocos días le han hecho una entrevista en un podcast bastante conocido (que no conocía). La entrevista es tan larga como interesante (puedes encontrar resúmenes por ahí), así que da para hablar de bastantes temas: VR, redes sociales y sus problemas, el tema sobre cuantas horas hay que trabajar, coches, videojuegos… en todos ellos su visión es muy muy sensata aunque creo que el hecho de trabajar en Oculus (comprada por facebook) le hace tener una posición un poco sesgada sobre lo que la cúpula de facebook piensa.

Dejando a un lado esa posición sesgada y que está maravillado con su Tesla… hay dos temas que me han llamado la atención poderosamente:

El primero es cuando habla sobre la cantidad de horas que trabaja. Comenta que él solo puede ser productivo 13 horas al día… últimamente ha habido una gran cantidad de comentarios sobre este tema dando recomendaciones sobre cuanto trabajar. En mi vida ha habido periodos donde he trabajado 10-12 horas al día y no los cambiaría por nada. No es sostenible ni para todo el mundo, obviamente, y cada periodo de la vida tiene diferentes prioridades, pero en mi opinión es complicado ser muy bueno en algo si no inviertes una buena cantidad de horas. De ahí que esté un poco de acuerdo con Carmack aquí sobre que cada uno elija libremente las horas que puede o no trabajar (sabiendo, eso sí, que hay vida necesaria más allá que el editor de código)

El segundo, y más importante, es cuando habla de la velocidad de computación

Las máquinas están empezando a ser más lentas, no en absoluto, pero la velocidad a la que la velocidad crece ha bajado dramáticamente. Y el punto está en que, según carmack, los móviles están llegando al límite de lo que pueden dar.

Como derivada, y esta es la parte más llamativa, habla de un cambio cultural, tenemos que empezar a volver a pensar en el performance. Y no es el único, cada semana veo varios artículos sobre como la web está a rebosar de código que hace que vaya lento en todo lo que no sean móviles de última generación. La gente ya no sabe que pasa debajo del código que hace (React, te estoy mirando a ti) y en general se tiende a pensar que con levantar unas cuantas máquinas más en AWS resuelve todos los problemas. Aquí una charla de otro de mis favoritos, hablando precisamente de como el hecho de que los desarrolladores actuales no tengamos ni puñetera idea de lo que pasa por debajo es algo muy muy malo en un futuro próximo (un poco apocalítico, pero bueno)

No puedo estar más agradecido de haber empezado mi carrera profesional haciendo videojuegos, donde tener que refrescar millones de pixeles 60 veces por segundo hacía que el “performance” fuese un ciudadano de primera.

Hablaré más sobre este tema en futuros post

Qué he estado escribiendo esta semana

Este mes de agosto he escrito bastante pero he publicado muy poco, cosas de las vacaciones y que por otro lado dejo madurar los posts unos días para ver si pasan el test de la lectura después de una semana.He avanzado con mi serie de post sobre el data lake, en esta entrega la trazabilidad

Estoy escribiendo esta serie con dos objetivos: 1) Que alguien que se pregunte qué leches es un “data lake” lo sepa 2) Demostrar que un daka lake es una panacea y que no deberías hacer algo así.

En qué estoy trabajando

Casi todas las bases de datos tienen sistemas para planificar como van a ejecutar una query en base a unas estadísticas sobre los datos. Suelen ser sistemas complejísimos y a veces tienes que saber como funcionan para optimizar bien las queries.

Clickhouse, mi base de datos favorita, no tiene un planificador (tiene algo muy simple, que dicho sea de paso simplifica todo el diseño), no obstante las queries se pueden ejecutar con diferentes parámetros. Estoy usando una aproximación diferente: en vez de calcular estadísticas de los datos y ver cual es el mejor plan, estoy ejecutando los diferentes tipos de queries con diferentes parámetros y entrenando un modelo de ML para luego saber cual es el mejor plan dados unos parámetros. De momento el modelo predice con exactitud el tiempo de ejecución (lo que me ha sorprendido gratamente).

El objetivo es integrarlo en Tinybird para los endpoints que tengas publicados. Publicaré los resultados en el blog de Tinybird

Hay aproximaciónes para usar ML en bases de datos, aquí un articulo brutal de como usar un modelo para sustituir a los índices tradicionales.

Extra lap

Si vas a leer algún link de esta lista, que sea este post de Feli, “tengo cáncer”

Te mando un correo cada vez que publico algo, con comentarios del director, claro