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 cómo aplicarlos en tu día a día—, junto con ejercicios prácticos para que los vivas por ti mismo.

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.

Además, los filósofos de la mente como Andy Clark y David Chalmers proponen la tesis de la "Mente Extendida". Argumentan que nuestras herramientas no son solo accesorios, sino partes literales de nuestro proceso cognitivo. El garrote del cavernícola y tu IDE (Entorno de Desarrollo Integrado) cumplen la misma función neurológica: descargan el procesamiento cognitivo al mundo físico.

Por tanto, cuando "golpeas piedras" o "refactorizas código", no solo estás trabajando; estás exteriorizando tu pensamiento para poder interactuar con él. El algoritmo es, en esencia, la versión más sofisticada de nuestra necesidad biológica de imponer orden al caos mediante herramientas externas.

Bajo esta luz, los pasos para resolver problemas no son elecciones arbitrarias de gestión empresarial, sino respuestas directas a nuestras limitaciones biológicas. Nuestro cerebro busca economía de energía (por eso escanea primero el entorno inmediato), tiene una memoria de trabajo limitada (por eso necesita externalizar ideas en prototipos para no colapsar) y aprende mediante predicción y error (ajustando sus modelos solo cuando la realidad choca con ellos).

No resolvemos problemas en línea recta porque la realidad es compleja e incierta; lo hacemos en bucles de retroalimentación. He aquí cómo ese antiguo mecanismo de supervivencia se traduce en tres principios operativos para el mundo moderno:

1. Usa lo que tienes

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 épico de creatividad con recursos limitados.

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. Con el tiempo, contrataron fotógrafos, pero el primer paso fue con lo que tenían en la mano.

Spotify, en sus inicios, no tenía servidores potentes ni sistemas complejos. Los fundadores alquilaban infraestructura básica y la adaptaban con ingenio, logrando transmitir música en un entorno que parecía insuficiente. Igual que un Homo habilis golpeando piedras, su clave fue usar lo que tenían 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 nuestros antepasados no esperaban a la herramienta ideal: afilaban una piedra y la convertían en su cuchillo multiusos. Hoy tampoco estás indefenso: siempre cuentas con algún recurso, por básico que parezca, para dar el primer paso.

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. La lógica es idéntica: sacar partido de lo inmediato.

Ponte en modo MacGyver mentalmente. ¿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 y tira de bibliotecas estándar. Muchas veces la solución “casera” con lo que ya tienes es suficiente para salir del apuro o al menos ganar tiempo.

En la Edad Media, campesinos reparaban sus herramientas con lo que encontraban en el campo. De la misma manera, un emprendedor moderno repara su modelo de negocio con hojas de cálculo antes de invertir en software costoso.

2. Prototipa

Leonardo da Vinci trabajaba igual: sus cuadernos estaban llenos de máquinas que no existieron físicamente, pero que le permitían explorar mecánicas. Es el mismo principio detrás de un wireframe en UX o un prototipo 3D hoy en día.

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. Así, un error en un prototipo barato evita un desastre en el mercado.

Dropbox nunca construyó un prototipo funcional al principio. Lo que hizo fue grabar un video mostrando cómo se usaría el servicio de almacenamiento en la nube. Ese clip atrajo miles de suscriptores interesados 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. Cuando haces un boceto, un modelo o un código mínimo viable, de inmediato saltan a la vista los problemas y aciertos. Esa app que imaginas, ¿funciona su concepto? Haz una demo cutre en PowerPoint. ¿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, Producto Mínimo Viable). No importa que sea feo o incompleto; importa que exista.

Los artesanos medievales probaban primero en madera antes de tallar en piedra definitiva. Igual que un diseñador UX prueba con wireframes antes de gastar en desarrollo.

Al prototipar, adoptas una actitud juguetona y experimental. En vez de apostarlo todo a una gran solución final, vas probando pequeñas soluciones intermedias. Cada prototipo te enseña algo: “¿funciona esto en la práctica?”, “¿qué opinan los demás?”. Con esas lecciones, ajustas el rumbo. Recuerda: es mucho mejor corregir errores en un prototipo barato que en un producto terminado costoso.

3. Equivócate rápido

Los navegantes fenicios que se desviaban de su ruta, buscando nuevas rutas comerciales, descubrieron puertos y tierras desconocidas. Esa capacidad de transformar un 'error de navegación' en una oportunidad es la misma que vemos en startups que pivotan hacia modelos de negocio más prometedores.

Slack nació como un producto secundario: era la herramienta de mensajería interna de un videojuego que fracasó. En lugar de hundirse, los fundadores reconocieron el valor de esa 'función secundaria' y la convirtieron en el producto principal. Hoy es una de las plataformas de comunicación más usadas en empresas.

Netflix arrancó alquilando DVDs por correo y hasta intentó vender la empresa a Blockbuster. El rechazo los obligó a repensar el negocio y apostar por el streaming, que terminó revolucionando el entretenimiento. Un error inicial abrió la puerta a su mayor éxito.

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. Dicho de otro modo: si vas a fallar, que sea en pequeño y pronto, no en grande y tarde. Así podrás ajustar el rumbo rápidamente.

Los alquimistas del Renacimiento fallaron incontables veces en su búsqueda de oro, pero cada error alimentaba nuevos descubrimientos químicos. Hoy, los errores en un laboratorio o en un repositorio de Git hacen lo mismo.

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” (falla rápido, falla con frecuencia). 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? 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. Como dijo Edison:

“No he fracasado. He encontrado 10.000 maneras que no funcionan.”

— Thomas Edison

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?”. Felicítate incluso: ya sabes una manera menos de hacerlo, estás depurando el camino.

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 (Zappos), 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 de "algoritmo 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, no había un sistema automatizado ni robots en un almacén. 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ó. Fue un fracaso rotundo. 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.

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