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