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
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.
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.
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.
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.
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.
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.
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.