Del garrote al algoritmo: una historia de cómo resolvemos problemas

Imagina a un humano primitivo, de hace miles de años, agachado junto al fuego de su cueva. Con ojos atentos, golpea una piedra contra otra una y otra vez hasta obtener un filo cortante. Sus manos están toscas, pero perseveran: quiere un arma sencilla para cazar o defenderse, usando solo lo que tiene a su alrededor.

Ahora mírate a ti, en pleno siglo XXI, pegado a la pantalla mientras intentas depurar ese código rebelde a las 2 a.m. Llevas horas probando distintas soluciones, sudando y refunfuñando, decidido a arreglar ese bug antes de dormir. A tu manera, también estás golpeando piedras: probando e iterando con las herramientas digitales disponibles.

Dos escenas separadas por milenios, pero con algo fundamental en común: en esencia, resolver problemas es nuestra gran ventaja evolutiva. Podrán cambiar las herramientas —garrotes, palancas, algoritmos—, pero la mentalidad de fondo permanece. Observamos, experimentamos, aprendemos de los fallos... y lo volvemos a intentar. Las tecnologías se transforman, pero los principios perduran.

Resolver problemas es nuestro superpoder como especie. Las herramientas evolucionan con el tiempo; los principios básicos —observar, iterar, abstraer— permanecen intactos.

La historia nos regala paralelos fascinantes entre ayer y hoy:

• Hace 2 millones de años: un Homo habilis golpea un canto rodado para fabricar un cuchillo de piedra. Hoy: un desarrollador reutiliza un script disponible para armar rápidamente una función. En ambos casos, aprovechando al máximo los recursos disponibles.
• Siglo XV: Leonardo da Vinci bosqueja y construye modelos rudimentarios de sus inventos para probar cómo funcionarían. Hoy: un ingeniero diseña un prototipo exprés con impresión 3D antes de fabricar el producto final. Probar primero en pequeño para iterar barato.
• Siglo XIX: Thomas Edison ensaya decenas de filamentos hasta dar con uno que ilumina sin quemarse. Hoy: una startup lanza versiones beta de su app semana tras semana, aprendiendo de cada fallo. Fallar pronto para corregir rápido.
• Antigüedad: navegantes trazan mapas estelares simplificados para orientarse por la noche. Hoy: un programador esquematiza un problema complejo en pseudocódigo antes de escribir una sola línea de código. Abstraer la realidad para entenderla y resolverla mejor.

¿Notas el patrón? Distintas épocas, mismas estrategias mentales. Desde el troglodita hasta el desarrollador moderno, todos observan su situación, usan lo que tienen a mano, hacen pruebas y aprenden de lo que no resulta. Veamos ahora tres principios atemporales detrás de este proceso, y por qué nuestro propio cerebro los hace inevitables.

Por qué no podemos dejar de resolver

Para entender por qué actuamos así, debemos mirar bajo el capó de nuestra propia biología. Desde la antropología y la psicología evolutiva, se sugiere que los humanos ocupamos lo que se llama el "nicho cognitivo". A diferencia de otras especies que desarrollaron garras más afiladas o pieles más gruesas para sobrevivir, nosotros desarrollamos una capacidad única para crear modelos mentales de la realidad y manipularlos.

Psicológicamente, no vemos una piedra solo como una piedra, ni una línea de código solo como texto. Vemos "affordances", posibilidades de acción. Donde un animal ve un obstáculo, el cerebro humano proyecta una herramienta. Esta capacidad de abstracción es lo que nos permite separar la función de la forma: el Homo habilis no veía sílex, veía un cuchillo potencial.

Los filósofos de la mente Andy Clark y David Chalmers propusieron algo aún más radical con su tesis de la "Mente Extendida": nuestras herramientas no son accesorios, sino partes literales de nuestro proceso cognitivo. El garrote del cavernícola y tu IDE cumplen la misma función neurológica, descargar el procesamiento cognitivo al mundo físico para poder interactuar con él. Cuando "golpeas piedras" o "refactorizas código", no solo estás trabajando; estás exteriorizando tu pensamiento para poder verlo, tocarlo y corregirlo.

Bajo esta luz, los tres principios que vienen a continuación no son técnicas de gestión ni mantras de startup. Son respuestas directas a las limitaciones del cerebro humano: nuestro cerebro busca economía de energía, por eso escanea primero el entorno inmediato en lugar de imaginar lo ideal; tiene una memoria de trabajo limitada, por eso necesita externalizar ideas en prototipos para no colapsar; y aprende por predicción y error, ajustando sus modelos solo cuando la realidad choca con ellos. El garrote no fue una elección filosófica. Fue la única respuesta que un cerebro con esas características podía dar.

1. Usa lo que tienes

Mucho antes de que existieran las startups, los artesanos medievales reparaban sus arados con lo que encontraban en el campo. No esperaban al herrero del pueblo si podían improvisar con un trozo de madera y una cuerda. La escasez no era un obstáculo para actuar: era la condición normal de actuar. Ese instinto de "usa lo que hay" no desapareció con la industrialización; solo cambió de material.

La NASA, durante la crisis del Apolo 13, improvisó un sistema para filtrar dióxido de carbono con cinta adhesiva, bolsas de plástico y manuales arrancados. Sin ese ingenio, los astronautas habrían perecido. Un ejemplo extremo, pero que ilustra el principio con claridad meridiana: los ingenieros no esperaron a tener las herramientas correctas porque no había tiempo. Tenían que resolver el problema con lo que estaba dentro de la cápsula.

Airbnb comenzó con algo muy rudimentario: fotos caseras tomadas por los propios fundadores para mostrar los departamentos. Aquellas imágenes, aunque poco profesionales, sirvieron para validar el concepto de alquilar espacios privados. Spotify, en sus inicios, no tenía servidores potentes. Los fundadores alquilaban infraestructura básica y la adaptaban con ingenio. Igual que un Homo habilis golpeando piedras, la clave fue usar lo disponible en vez de esperar a tener lo ideal.

Una trampa común al afrontar un problema es pensar que necesitas algo más: "si tan solo tuviera tal herramienta, o más presupuesto, o el equipo perfecto… entonces sí podría resolverlo". Pero nuestro cerebro, con su economía de energía y su memoria de trabajo limitada, no está diseñado para esperar la solución óptima en abstracto. Está diseñado para actuar sobre lo que tiene delante y corregir sobre la marcha. El garrote era la herramienta perfecta no porque fuera perfecta, sino porque era la que estaba al alcance cuando había hambre.

Así como un Homo habilis transformaba un simple canto rodado en cuchillo, hoy un programador convierte un editor de texto común en un entorno de desarrollo improvisado. Ponte en modo MacGyver. ¿No tienes el software más nuevo? Usa Excel o papel y lápiz si hace falta. ¿No conoces ese framework de moda? Apóyate en el lenguaje que dominas. Muchas veces la solución casera con lo que ya tienes es suficiente para salir del apuro, ganar tiempo, y aprender qué necesitas realmente para el siguiente paso.

2. Prototipa

En el siglo XV, los cuadernos de Leonardo da Vinci estaban llenos de máquinas que nunca existieron físicamente. Eso no era un fracaso: era el método. Leonardo sabía que explorar una mecánica sobre papel era infinitamente más barato que construirla en hierro y descubrir que no funcionaba. No esperaba a tener la certeza teórica para actuar, ni esperaba a tener los recursos para construir el objeto final. Bajaba la idea al mundo, aunque fuera en papel, para poder interactuar con ella. Recordemos la mente extendida: solo puedes corregir lo que puedes tocar.

Tesla, en lugar de diseñar coches en completo secreto hasta su lanzamiento, muestra prototipos y los prueba en pista frente a cámaras y usuarios. Cada fallo registrado alimenta la siguiente versión. Dropbox nunca construyó un prototipo funcional al principio: grabó un video mostrando cómo se usaría el servicio. Ese clip atrajo miles de suscriptores antes de escribir una sola línea de código sólida, validando la idea sin producto real.

¿Recuerdas cuando, de niño, construías castillos de bloques solo para derribarlos y construir otro mejor? Sin saberlo, ya practicabas el arte del prototipado. Consiste en hacer una versión simple y temprana de tu idea para ver qué tal va. En lugar de pasarte semanas planificando la solución perfecta en tu cabeza, la bajas a la realidad en horas —o minutos— con algo que casi da risa de lo simple que es… pero que funciona lo justo para darte información valiosa.

Prototipar te libera de la parálisis por análisis porque obliga al cerebro a hacer exactamente lo que mejor sabe: reaccionar a algo real, no imaginar algo hipotético. ¿Quieres escribir un libro? Redacta un artículo corto con la idea central. ¿Tienes una startup en mente? Construye en un día la versión más básica, lo que llaman un MVP o Producto Mínimo Viable. No importa que sea feo o incompleto; importa que exista. Al prototipar, cada versión intermedia te enseña algo que ninguna cantidad de planificación podía enseñarte: "¿funciona esto en la práctica?", "¿qué opinan los demás?". Con esas lecciones, ajustas el rumbo. Es mucho mejor corregir errores en un prototipo barato que en un producto terminado costoso.

3. Equivócate rápido

Nadie quiere fallar, pero postergar un posible error no lo hace menos doloroso: solo lo hace más caro. Por eso uno de los secretos para resolver problemas con éxito es equivocarte cuanto antes. Si vas a fallar, que sea en pequeño y pronto, no en grande y tarde. Así podrás ajustar el rumbo rápidamente.

Mira a los niños cuando aprenden a caminar: se caen docenas de veces, ríen, lloran un poquito, y vuelven a intentarlo hasta que un día echan a andar. Esa resiliencia natural la vamos perdiendo de adultos por miedo al fracaso o al qué dirán. Nos volvemos más precavidos, a veces demasiado: analizamos y analizamos, buscando evitar cualquier error… y terminamos paralizados o llegando tarde. Paradójicamente, los errores tempranos son los que te ahorran errores mayores después.

En el mundo del software y las startups se popularizó el mantra "fail fast, fail often". Cada mini-fallo es una lección que te hace más fuerte y sabio para el siguiente intento. Lanzar esa campaña que quizá no funciona, publicar esa versión 0.1 con bugs, atreverse con ese experimento loco en tu proyecto: todo eso te da datos reales y experiencia. En cambio, esperar eternamente por la solución perfecta solo te da ilusiones teóricas.

¿Qué es lo peor que puede pasar si algo sale mal en ese terreno de bajo riesgo? Probablemente no tanto como crees: corregir sobre la marcha, disculparte si hace falta, y continuar. En cambio, ¿qué es lo mejor que puede pasar si lo intentas ya? Que encuentres antes la forma en que sí funciona. Cada intento fallido no es un verdadero fracaso, sino un paso más cerca del acierto, siempre y cuando aprendas de él. Así que pierde el miedo a equivocarte en pequeño. Púlsalo todo, rompe cosas en ambiente de pruebas, pregunta lo que creías "tonto", atrévete a hacer el ridículo creativo. La próxima vez que algo no salga bien a la primera, en lugar de hundirte pregúntate: "¿Qué acabo de aprender con esto?".

3 historias que cambiaron el mundo

La teoría aguanta todo en el papel, pero es en el caos de la realidad donde estos principios demuestran su valor. Aquí tienes tres historias de personas que, enfrentadas a problemas imposibles, decidieron soltar el manual.

1. Los mecánicos de bicicletas vs. La élite científica (Usa lo que tienes)

A principios del siglo XX, la carrera por conquistar los cielos tenía un claro favorito: Samuel Langley. Era el candidato perfecto sobre el papel. Secretario del Instituto Smithsoniano y amigo de Alexander Graham Bell, Langley contaba con 50.000 dólares del Departamento de Guerra —una fortuna para la época— y el acceso a las mentes más brillantes de la academia. Su enfoque era el de la "Gran Ingeniería": construyó una catapulta gigante en una casa flotante sobre el río Potomac para lanzar su "Gran Aeródromo". Creía que si los cálculos teóricos eran perfectos, el vuelo sería inevitable.

A cientos de kilómetros, en Dayton, Ohio, Orville y Wilbur Wright no tenían subvenciones, ni credenciales universitarias, ni prensa siguiéndoles. Tenían un taller de bicicletas. Mientras Langley gastaba miles de dólares en materiales exóticos, los Wright aplicaron el principio de la "tecnología adyacente". Entendieron que volar no era un problema de potencia —como creía Langley—, sino de equilibrio, muy similar a montar en bici.

Para probar sus teorías, no construyeron un túnel de viento industrial; hicieron una caja de madera con un ventilador casero y usaron radios de bicicleta aplanados para medir la resistencia del aire. Usaron cadenas y piñones de su taller para el sistema de transmisión del avión. El 8 de diciembre de 1903, el sofisticado aparato de Langley se estrelló ignominiosamente en el río al despegar. Nueve días después, el "garrote" de madera y tela de los Wright volaba sobre las dunas de Kitty Hawk. Langley quería la máquina perfecta; los Wright querían una herramienta que funcionara.

2. El almacén fantasma de Zappos (Prototipa / Finge hasta que lo logres)

En 1999, la idea de comprar zapatos por internet sonaba ridícula. "¿Cómo voy a saber si me quedan bien?", decía la gente. Nick Swinmurn tenía la visión de crear el mayor catálogo de zapatos del mundo, pero se enfrentaba al clásico problema del huevo y la gallina: necesitaba millones de dólares en inventario para montar la tienda, pero ningún inversor le daría dinero sin demostrar que la gente compraría.

El enfoque tradicional hubiera sido redactar un plan de negocio de 100 páginas, alquilar un almacén y contratar un equipo de logística. Swinmurn optó por un enfoque casi cavernícola: el "Mago de Oz". Fue a una zapatería local en su barrio y le preguntó al dueño: "¿Te importa si hago fotos a tus zapatos? Si alguien me los compra online, vendré aquí y te los pagaré al precio normal".

Montó una web estática y fea. Cuando caía un pedido, el "sistema" era Nick corriendo a la tienda, comprando los zapatos con su tarjeta de crédito y llevándolos a la oficina de correos. Perdía dinero en cada envío, pero ganó el dato más valioso de la industria: la validación del comportamiento humano. Había simulado un gigante del comercio electrónico usando solo una cámara y sus propias piernas. Hoy, esa validación vale más de 1.000 millones de dólares.

3. El fracaso repetido de Stewart Butterfield (Equivócate rápido y recicla)

En la biología evolutiva existe el concepto de "exaptación": cuando un rasgo evoluciona para una función pero termina siendo útil para otra completamente distinta, como las plumas, que eran para el calor y terminaron sirviendo para volar. En tecnología, Stewart Butterfield es el maestro de la exaptación.

En 2004, Butterfield intentó lanzar un videojuego masivo llamado Game Neverending. El juego era complejo y ambicioso, pero el mercado lo rechazó. Sin embargo, mientras desmantelaban el código para cerrar la empresa, notaron que la pequeña herramienta que habían creado para subir fotos dentro del juego era extrañamente adictiva. Decidieron tirar el 90% del código del juego a la basura y salvar solo esa pequeña función. La llamaron Flickr, y revolucionó la web social.

Años después, la historia se repitió. Butterfield lanzó otro juego, Glitch. Volvió a fallar estrepitosamente. Pero su equipo, trabajando en distintas ciudades, había creado una herramienta interna de chat muy rudimentaria para no tener que usar el correo electrónico. Era fea y básica, un simple "garrote" de comunicación. Al cerrar el estudio de videojuegos, Butterfield se dio cuenta de que ese chat era lo único que funcionaba sin fallos. Lo pulieron y lo lanzaron al mundo como Slack. Dos de las herramientas más icónicas de internet no nacieron de un plan maestro, sino de reciclar los escombros de un fracaso.

Vale añadir aquí la advertencia del punto anterior: Butterfield tuvo dos fracasos y dos exaptaciones extraordinarias. Eso es excepcional. La lección no es que fallar siempre conduzca a algo mejor, sino que si prestas atención mientras fallas, es mucho más probable que reconozcas el valor cuando aparece en un lugar inesperado. No es el fallo lo que hizo posible Slack: fue la mirada que supo ver el chat donde otros habrían visto solo escombros.

La trampa biológica: por qué odiamos la simplicidad

Si estos principios son tan lógicos —usar lo que hay, probar rápido, simplificar—, ¿por qué nos cuesta tanto aplicarlos? ¿Por qué nuestra tendencia natural es construir sistemas barrocos, planificar durante meses y buscar la herramienta más cara?

La respuesta está de nuevo en nuestra configuración mental. Un estudio publicado en la revista Nature reveló que los seres humanos tenemos un "Sesgo de Adición". Cuando se nos pide mejorar una estructura —ya sea un puente de Lego, una receta de cocina o un algoritmo—, nuestro cerebro instintivamente busca qué añadir. Casi nunca pensamos en qué quitar.

Evolutivamente, "más" solía significar "mejor": más comida, más refugio, más herramientas. Pero en la resolución de problemas modernos, este instinto es una trampa.

• El programador novato cree que para ser "senior" debe escribir código complejo; el verdadero maestro sabe que su trabajo es reducir la complejidad.
• El emprendedor asume que necesita más capital y más empleados; el innovador real busca cómo hacer más con menos recursos.

Hay una ironía aquí que conviene nombrar: el sesgo de adición es también un producto de la mente extendida. Cuando tenemos acceso a más herramientas, más recursos, más opciones, el cerebro tiende a usarlos todos porque "están ahí". El Homo habilis no tenía ese problema: tenía la piedra que había. Nosotros tenemos que practicar activamente la restricción que él tenía por defecto. La simplicidad, en el mundo moderno, es una decisión deliberada, no una limitación impuesta.

El garrote que nunca cambió

Volvamos al inicio. El Homo habilis agachado junto al fuego no sabía que estaba inventando la tecnología. Solo sabía que tenía una piedra, un problema y hambre. Lo que convirtió esa piedra en herramienta no fue un plan maestro ni los recursos correctos ni la certeza de que iba a funcionar. Fue algo más antiguo y más simple: la disposición a actuar con lo que había, ver qué pasaba, y corregir.

Milenios después, el programador que depura código a las 2 de la mañana hace exactamente lo mismo. Cambia el material, cambia la pantalla, cambia el lenguaje. El bucle es idéntico: observa la situación, usa lo que tienes a mano, baja la idea al mundo antes de que sea perfecta, y aprende de lo que no funciona. Clark y Chalmers tenían razón: el garrote no era solo una herramienta externa. Era una extensión del pensamiento, una forma de convertir una idea en algo que el mundo podía responder.

Cada generación cree que sus problemas son nuevos y que necesita soluciones radicalmente distintas. A veces es verdad. Pero la mayor parte del tiempo, los principios de fondo son los mismos que usó el primer Homo habilis que decidió que una piedra podía ser algo más que una piedra. No necesitas más herramientas. No necesitas el plan perfecto. No necesitas esperar a tener todo listo.

Necesitas golpear la piedra y ver qué pasa.