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.
El otro día Elon Musk tuiteaba esto (es interesante leer las respuestas, sobre todo las suyas)
Tesla is developing a NN training computer called Dojo to process truly vast amounts of video data. It’s a beast! Please consider joining our AI or computer/chip teams if this sounds interesting.
— Elon Musk (@elonmusk) August 14, 2020
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.
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.
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.
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.
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