Los odio, y no porque me parezcan malos, los he usado, los uso y los usaré por el resto de mis días como programador. Un framework no deja de ser una forma más o menos cerrada de resolver un problema donde la mayoría de los casos de uso más o menos comunes han sido simplificados. Nada tienen de malo y mucho de bueno.
El gran problema viene cuando el framework es el foco.
Cuando la gente piensa que su carencia de conocimiento la puede paliar con un framework, cuando da igual el negocio que modeles, el framework es el santo grial, crees que cualquier problema complejo lo vas a solucionar con el framework. Uso react y redux y con esto todas mis condiciones de carrera se irán.
Y parece que sí porque te da un modelo con el que trabajar, cuando comienzas cualquier proyecto lo básico suele ser muy parecido y los retos son más bien sencillos. El framework te da ese subidón de “lo estoy partiendo”, “voy a toda leche”, te enamoras de él.
Pero pronto se acaba la alegría cuando empiezas a modelar el negocio de verdad y ves que el framework es una pequeña ayuda, entonces intentas apalancarte en el framework como forma de solucionar todo, y termina por ser el que marca todo: tu arquitectura, tus herramientas y hasta el cómo contratas.
El CTO o lead developer se ve acorralado porque sus desarrolladores dicen que XXX es mejor que lo que estamos usando ahora. “Si usasemos XXX todo irá mucho más rápido”. Todo vale si el desarrollador está feliz, de otro modo se irá a la empresa que sí usa XXX. No te preocupes, no tardará en salir la voz que no entienda que la cultura de empresa pasa por no hablar de frameworks y sí de problemas y soluciones.
No irá más rápido, no será mejor, lo que pasa que volverás al primer paso donde los problemas sencillos se adaptan bien a lo que el framework te da.
De mientras todas tus ofertas de trabajo ya tienen “empresa YYYY busca personas para desarrollar en XXX”. Ya todas tus conversaciones son sobre el último plugin o el fork del framework. Toda tu tecnología está basada en XXX, Todos tus desarrolladores quieren ir a “XXX Con” en SF, donde todos los mayores expertos se reúnen para enseñar las maravillas de XXX (ellos sí son listos, sí tienen una ventaja al crear la tecnología). Las voces que comentan lo complicado que es hacer algo con el framework son rápidamente acalladas, todas las bondades que hemos vendido se irían al traste.
Toda tu estrategia tecnológica, de adquisición y mantenimiento de talento se ha basado en usar un framework. Toda tu estrategia se ha basado en usar algo que todas las empresas tienen disponible.
Los que se vienen por un framework se irán por otro.
Un buen desarrollador no mira al framework, mira a la forma de resolver los problemas con el framework, lo entiende, sabe cuando y como usarlo, entiende que la tecnología avanza y que su código funcionando en producción de forma robusta, resolviendo problemas dejará de usar algo novedoso (cosa, por otro lado normal en absolutamente todas las industrias. Debemos ser los únicos que no nos sentimos orgullosos de nuestro pasado)
El buen desarrollador usa un framework porque sabe lo que hay debajo, no para evitarlo.
Una buena empresa es buena porque se enfoca en resolver el problema por el que le pagan y eso incluye desde el CEO hasta el desarrollador.
Empiezas a desarrollar tu producto y pasas por las siguientes fases:
El problema es que piensas que tienes tiempo infinito. Si el tiempo es finito, qué sentido tiene tener un sistema que solo crece?
Mi teoría es que cualquier herramienta que en una empresa permita generar contenido libremente y sin una estructura definida va a ser un problema en algún momento. Ejemplos: mail, wikis, tickets, documentos, slack…
En cualquier caso, este post de Joel on Software, Software inventory es básicamente lo que cualquier empresa debe recordar todos los días. No he visto nada hasta la fecha que sintetize mejor las reglas para tener un buen proceso de desarrollo de producto que ese post.
De hecho, como el tiempo es limitado hubo alguien que pensó en que alguien debería tener un rol para priorizar, llamado el product manager, que en mi opinión es fundamental, sobretodo para descartar más que para añadir (que suele ser lo habitual) y no solo en el momento de creación de tickets/features, si no durante el proceso de desarrollo de las mismas.
No hay solución, sobre todo si vas a muerte y no tienes tiempo de hacer tareas de mantenimiento. A quién le gusta revisar los tickets, ver si las features planteadas tienen sentido? Lo que NO es la solución es buscar una herramienta que solucione un problema de base, está bien buscar una herramienta que te ayude mapear tu proceso a lo digital, pero esa herramienta no va a solucionar un problema que está en las personas, esas son las que debes entrenar.
Pero claro, para que una persona sepa discernir entre algo que tiene sentido registrar y algo que no debe tener una visión más allá de la “siguiente tarea”. Cuando transmitir los objetivos de forma clara no se hace entonces se habla de que hay “problemas de comunicación”, pero eso es para otro post.
Uno de mis sueños es algún crear un sistema de tickets/mail donde se tenga dinero y cada cosa que pongas cueste dinero (se podrían implementar usando blockchain, lo mismo puedo levantar una rondita), tampoco iba a solucionar el problema, pero por lo menos haría visible el problema para todos.
En cualquier caso, si vas a pasar a Jira, por favor, integra el repositorio de código con él, no se te paso por la cabeza el “duplico los tickets que necesite” o hago las referencias manualmente. E invierte tiempo con el equipo, sea Jira o sea un fichero CSV.
Mañana hará dos meses que dejé CARTO. Dejar un trabajo nunca es fácil, ya lo sabes, pero en este caso ha sido especialmente complicado, han sido muchos años y mucha gente, así que después de unos meses dándole más vueltas de las debidas decidí irme.
Estos meses de retiro dan para pensar muchas cosas, entre ellas echar la vista atrás y darte cuenta de los más de 6 años han sido tan duros como gratificantes, que la decisión que has tomado no podía haber sido más acertada y que lo mejor de CARTO sigue conmigo a pesar de no estar en el día a día.
Es difícil resumir todos estos años en un post, traté de hacerlo los días antes de irme y decidí quedarme con el buen sabor de boca más que con detalles o anécdotas del pasado. Creo que el mejor resumen es el correo que envié a toda la gente que trabajaba en CARTO unas semanas antes de irme:
…
Hello everybody
You know I hate bullshit, I hate decorating things just for the sake of making them look better (and not being truly) so please, read this email with that mindset. Here it goes.
I’m leaving CARTO.
The question in your mind is probably “but why?”, let me explain. It’s been more than 6 awesome years working here and I feel tired. Because of that (and some other not so important reasons, of course) I know for sure that I will not have the kick that my position requires to take the team where it needs to get.
Next thing I’d like to say, and the most important one in this email, is thank you. Really. Having the opportunity to work here, seeing how CARTO grew from 6 guys to a big (well, medium size) company, becoming the tech leader and on top of that, sharing my time with a group of outstanding people (that happened to be working for the same company, lucky me) is something I’ll be grateful for, for the rest of my life.
New and good things are to come. I’m leaving and that gives the awesome [technical] team some more space to make their own decisions. Keep this in mind, this is the best team I’ve ever seen so I have no doubt that this company will succeed, so “look to the future and leave the past behind”. I’ll be looking to you guys (sorry about the extra pressure)
I’d like to also apologize for those moments where I didn’t act in a professional enough way, I was too rude or didn’t treat you with the right amount of human touch.
So thank you again, I’ll be around for some more weeks, happy to talk to you whenever you like.
VAMOS!
…
“Y ahora qué vas a hacer?” es la pregunta que todo el mundo me hace. Pues no lo he pensado, ni quiero, así que cuando vea algo que realmente me apetece realmente hacer, lo sabré :).
De nuevo, gracias a todo el mundo con el que he trabajado, me ha dado una oportunidad o me ha dado un collejón cuando tocaba, para bien o para mal estoy aquí gracias a vosotros.
I was checking my notes and I found this email I sent to my team some months ago when we decided to set up a dedicated team for tech “research”. You probably know that moment in which every medium-size startup acknowledges the lack of “innovation” but it’s impossible to articulate a good process to make it happen within the tech team because of the high workload. In order to get old times back and recover the magic of a 5 people team you decide to create a “research team”.
I consider these ones the backbone of a technology research team within a company. And this is a personal opinion and the way I like to do things so don’t get them as a dogma.
(I modified it a little bit to remove some not really important details about CARTO)
…
Hello team,
Investing time on important things is always a good choice. It’s like investing in your own health, you are not going to regret it. It does pay off after some time tho. It’s easy to get distracted by short-term urgent stuff (MRR driven most of the times)
People need space. That means people need time to think, make decisions and fail. You can’t pretend people to generate value if they don’t have they own opinions/ideas.
Moving data here and there is not going to push CARTO to the sky. We need to do very well at something. That something is hard by nature and hard things require time.
Long-term rather than short-term: we are too used to thinking short term, thinking long-term requires willpower and knowledge. It’s easy to think “with this shortcut we could get to production early” or “I don’t see short-term results for this and I’m going to look like a failure”.
Focus on one thing at a time. It should be the most important thing and we should own it: you shouldn’t be afraid of touching anything there because of the lack of ownership.
Everything should be though to end in production. Not only that, it should push production forward so it helps to get rid of deprecated technology, renews the internals and keeps the platform healthy.
Cheers.
Iba por el pasillo de la facultad, donde estaban los despachos de los profesores, echando un ojo a los típicas hojas pegadas en las puertas con propuestas de proyectos fin de carrera. Me llamaron la atención dos, uno para facilitar la movilidad a gente que usa silla de ruedas y otro sobre un tema agrícola. Después de hablar con los dos profesores me decanté por el agrícola, después de todo años atrás había ido con mi padre a echarle un cable en las tareas del campo, así que me tocaba un poco la patata, al final las cosas que te motivan las haces porque te tocan la fibra y no el bolsillo. Y así empezó agroguia un producto que con tecnología resolvía un problema que muchos agricultores tenían: poder medir distancias en el campo con sus tractores.
Tuve la suerte de que ese profesor, Jaime Gomez Gil, era además de agricultor e ingeniero, un tío brillante, con la cabeza sobre los hombros y con pasión por el tema. Mes tras mes trabajamos en el prototipo, de mientras trabajaba con una beca de la friolera de 400 euracos al mes en TV Castilla y León poniendo cables. Cuando terminamos el proyecto resultó no ser tan malo (algo cutre sí), decidí venderlo, total ¿por qué no? otros ponian a la venta cosas peores. Y lo hice, con unos 600€ (tuve que romper el cerdito) de inversión compramos lo necesario y a la calle a vender! creo que mejor que te lo cuente es que veas el video que creamos, creo que resume, en el técnico y emocional, lo que es agroguía.
No voy a contar de nuevo la historia de agroguía, la he contado en charlas, hemos salido en la tele, periódicos (internacionales también), blogposts, puedes buscarlas si estás interesado. Como detalle curioso cuando empecé a trabajar para Vizzuality (la empresa de donde salió CARTO) la gente me conocía por “el fulano de los tractores” o “el de las provincias” (algún día alguien me contará el porqué algunos lo usan en tono despectivo).
Este verano, después de pasar unos últimos años donde apenas habíamos dedicado tiempo y por tanto el negocio había bajado, decidimos transferir el negocio a nuestros partners y amigos Smartrural que sí pueden hacerse cargo y explotar el producto. Así que el 3 de Julio firmé lo que es el punto y aparte de un negocio de más de 12 años, significaba para mi deshacerme de algo que parí, he visto crecer y que ha sido mucho más que un producto.
Es difícil sacar conclusiones de tantos años pero en resumen estoy bastante contento aunque creo que contento no es exactamente la palabra, creo que es satisfecho.
Creamos una empresa en la que nos gustaba trabajar. No burocracia, nada forzado, trabajamos pocas horas al día. Por aquel entonces me leí “getting real” de 37signals (libro que deberías leerte) y disfruté cada página viendo como esta gente describía, de forma muy simple, lo que yo pensaba (aunque ellos lo han ejecutado mucho mejor). No molabamos nada, no usabamos tecnología puntera, pero daba igual.
Con la perspectiva de los años agroguía me parece un productazo y estoy muy orgulloso de la gestión de producto. Siempre muy enfocado, ha hecho y hace una sola cosa muy bien, hemos dicho que no a muchas cosas miles de veces. Técnicamente no es nada del otro mundo, son unas pocas miles de líneas de código, con algunos ficheros que no se han tocado en años y que ha sobrevivido durante 12 años sin despinarse pasando por varias generaciones de dispositivos móviles. Esto ahora lo llaman legacy, yo prefiero llamarlo “working code”.
Y no solo eso, creamos un negocio. No pensabamos en startups, queríamos ganar dinero resolviendo un problema que existía resolver un problema que resultó hacernos ganar dinero. Si muchas startups empezaran así ahora creo que nos iría mucho mejor, hay muchísimos problemas que resolver y por lo cuales la gente está dispuesta a pagar. Sin tener ni idea descubrimos lo que ahora llaman inbound, outbound, lead generation, SEO, venta online… y todo esto haciendo las cosas diferentes, sin mirar como lo hacían los demás, a pecho palomo (menudos inconscientes). En esa época escribía bastante en mi antiguo blog, puedes echar un vistazo a los posts. Aun recuerdo una conferencia donde el director comercial de una gran empresa de sistemas de agricultura de precisión (que por cierto nos han copiado varias veces) se reía de mi porque le dije que solo vendíamos por internet desde un pueblo de 800 habitantes en medio de la meseta.
No creamos un imperio, ni cambiamos el mundo, tampoco vendimos lo que no teníamos pero fuimos claros, hablamos con palabras que todo el mundo podía entender, hicimos la vida de algunas personas mejor, nos divertimos y aprendimos. Podría haber sido mucho más, el sector agrícola mueve muchísimo dinero, y créeme, necesitan tecnología, pero fue lo que quisimos que fuese.
Buena suerte amigos.