Sales de casa con una ruta bastante clara: caminar hasta cierta estación, tomar una línea del metro, cambiar en un punto determinado y bajar cerca de tu destino. Todo parece decidido hasta que una estación está cerrada. Entonces comparas alternativas, descartas una porque tarda demasiado, eliges otra y reajustas el recorrido.
No escribiste código ni abriste una aplicación de programación. Aun así, acabas de hacer algo que se parece mucho a una parte del pensamiento algorítmico: convertir un objetivo en una secuencia de pasos, incorporar condiciones y modificar el procedimiento cuando cambia la información disponible.
La palabra algoritmo suele aparecer hoy ligada a recomendaciones, redes sociales o inteligencia artificial. Ese uso es válido, pero es mucho más estrecho que el concepto original. Mucho antes de que un sistema decida qué video mostrarte, los algoritmos ya servían para describir procedimientos capaces de resolver problemas de forma ordenada.
Por eso reconocerlos fuera de una computadora ayuda a entender qué hacen dentro de ella. La vida cotidiana no está “programada” en sentido estricto, pero contiene decisiones, secuencias y repeticiones que pueden formalizarse como algoritmos.
Un algoritmo aparece cuando una intención se convierte en un procedimiento
Decir “quiero llegar a la universidad” expresa una meta. Todavía no describe cómo alcanzarla.
En cambio, cuando defines un punto de partida, eliges una ruta, estableces qué hacer si una conexión está cerrada y reconoces cuándo llegaste, ya existe un procedimiento mucho más preciso. En programación, esa precisión es indispensable porque una computadora no completa libremente lo que falta según el contexto humano.
La UNAM define un algoritmo como un conjunto finito de instrucciones o pasos claros para ejecutar una tarea o resolver un problema. La palabra finito importa: el procedimiento debe tener una forma de terminar. También importa que los pasos sean realizables y suficientemente precisos para conducir a un resultado.
Ahora bien, no toda costumbre cotidiana merece llamarse algoritmo con el mismo rigor. “Prepararme por la mañana” puede ser apenas una rutina vaga si cada día ocurre de manera distinta y muchas decisiones quedan implícitas. Si, por el contrario, especificas qué información necesitas, qué pasos realizas, en qué orden y qué condiciones cambian el recorrido, la descripción empieza a parecerse mucho más a un procedimiento algorítmico.
Esa diferencia evita una comparación demasiado fácil. Una receta, por ejemplo, puede ilustrar la idea de pasos ordenados, aunque no siempre esté escrita con la precisión necesaria para una máquina. “Cocina hasta que tenga buen aspecto” puede funcionar para una persona con experiencia; un programa necesitaría saber qué significa exactamente “buen aspecto” y cómo medirlo.
El material de Diseño de algoritmos de la UNAM parte justamente de la resolución de problemas: estudiar la situación, identificar sus elementos y construir pasos bien definidos que conduzcan a una solución. Antes de pensar en un lenguaje de programación, por tanto, ya hay trabajo intelectual en decidir qué procedimiento tiene sentido.
En la vida diaria ya combinas datos, decisiones y repeticiones
Volvamos a la ruta de transporte. Tu decisión no depende únicamente de una secuencia memorizada. También recibe datos: la hora, el estado de una línea, el tiempo disponible, quizá el costo o el clima. Con esa información aplicas reglas y eliges.
Algo parecido ocurre al organizar varias diligencias. Supongamos que necesitas ir al banco, recoger un paquete y comprar algo en un supermercado. Podrías visitar los lugares en el orden en que los recordaste; sin embargo, si observas horarios, distancias y tráfico, quizá reorganices el recorrido para evitar desplazamientos innecesarios.
Ahí ya no aparece solo una secuencia. Entran condiciones.
Si el banco cierra primero, conviene atenderlo antes. Si el paquete todavía no está disponible, lo dejas para el final. Si dos lugares quedan en la misma zona, los agrupas. Cada decisión modifica el siguiente paso, y esa relación entre información y acción es muy cercana a la lógica que después se formaliza en un programa.
La propia UNAM señala, en un material de bachillerato sobre datos, variables y algoritmos, que el concepto de algoritmo no pertenece exclusivamente a las matemáticas o la informática y que en la vida cotidiana utilizamos procedimientos para resolver problemas. La comparación resulta útil siempre que no olvidemos una diferencia: las personas toleran ambigüedad; las computadoras necesitan reglas mucho más explícitas.
También utilizamos repeticiones. Al revisar una lista de compras, recorres elemento por elemento y marcas lo que ya encontraste. Si falta algo, sigues buscando; cuando todos los elementos están resueltos o decides abandonar alguno, terminas. En el artículo sobre variables, condiciones y ciclos vimos esas mismas ideas dentro de programas: conservar información, decidir según una condición y repetir una operación.
La relación no significa que al caminar por un supermercado estés “ejecutando Python”. Significa que ciertos patrones de resolución de problemas pueden describirse de forma suficientemente ordenada como para transformarlos después en instrucciones programables.
El IIMAS de la UNAM trabaja precisamente esa conexión en sus actividades de pensamiento computacional, donde plantea la identificación de algoritmos en la vida cotidiana junto con lógica y solución de problemas. El objetivo no es convertir cada actividad humana en una computadora, sino aprender a reconocer estructura allí donde a primera vista solo vemos una tarea habitual.
El mismo problema puede admitir algoritmos muy distintos
Tener un procedimiento que funciona no significa que sea el único posible, ni siquiera el más conveniente.
Imagina que buscas el nombre de una persona en una libreta con quinientos contactos impresos. Puedes empezar en la primera página y revisar cada nombre hasta encontrarlo. Ese procedimiento funciona. Si el nombre aparece al final, no obstante, habrás recorrido casi toda la libreta.
Si los contactos están ordenados alfabéticamente, tienes otra posibilidad. Puedes abrir por una zona intermedia, comparar el apellido que ves con el que buscas y descartar de una vez una gran parte de las páginas. Después repites la operación sobre la parte restante.
Ambos métodos persiguen el mismo resultado, aunque el recorrido sea diferente.
Esta idea es central en informática porque un problema puede tener muchas soluciones correctas. Algunas requieren menos pasos; otras consumen menos memoria, son más fáciles de entender o funcionan mejor con cierta cantidad de datos. Por eso diseñar un algoritmo no se reduce a preguntar “¿funciona?”. A medida que los problemas crecen, también interesa saber cuánto trabajo exige.
La vida cotidiana ofrece versiones menos formales de esa comparación. Para ordenar una mesa llena de documentos puedes tomar el primer papel y buscar inmediatamente su carpeta; también puedes separar antes todos los documentos por tipo y archivarlos por grupos. Ningún método es universalmente mejor. Con cinco papeles, la diferencia apenas importa; con miles, la organización elegida cambia considerablemente el esfuerzo.
De ahí que la eficiencia tenga sentido solo en relación con el problema. Un procedimiento muy sofisticado puede ser innecesario para una tarea pequeña, mientras que una estrategia aparentemente simple deja de ser práctica cuando la cantidad de información aumenta.
La UNAM dedica un recurso específico a la evaluación de algoritmos, donde relaciona el desempeño con el tiempo de ejecución y los recursos empleados. Esa mirada añade una segunda pregunta después de “¿resuelve el problema?”: ¿qué costo tiene resolverlo de esa manera y cómo se comportará cuando aumente el trabajo?
Programar obliga a convertir las intuiciones en reglas que otra máquina pueda seguir
Las personas hacemos muchas cosas apoyándonos en conocimientos que nunca expresamos por completo.
Si alguien te pide ordenar varios libros “como siempre”, quizá sepas qué hacer porque conoces la casa, las categorías y las preferencias de esa persona. Una computadora carece de ese contexto compartido. Antes de ejecutar una tarea necesita recibir criterios observables: por autor, por título, por fecha, por tamaño o por alguna otra regla que pueda representarse.
Ahí aparece una transición importante entre resolver un problema intuitivamente y diseñar un algoritmo para un programa.
Primero hay que decidir cuáles son los datos de entrada. Después se definen operaciones, comparaciones y condiciones. También hace falta contemplar situaciones incómodas: ¿qué ocurre si falta información?, ¿si dos elementos son iguales?, ¿si no existe ninguna solución válida?, ¿si la entrada está vacía?
El recurso de la UNAM sobre sistematización de algoritmos explica que un problema puede dividirse en subproblemas más sencillos y que un algoritmo puede transformarse en un programa escrito en un lenguaje de programación. El código, por tanto, llega después de haber estructurado buena parte del problema.
Eso conecta con qué es programar y qué hace realmente un programador. Quien desarrolla software no pasa toda la jornada traduciendo ideas evidentes a sintaxis. A menudo tiene que descubrir primero qué significa realmente una petición, qué excepciones existen y qué procedimiento podrá mantenerse cuando los datos no sean los del ejemplo perfecto.
A veces, incluso, el mejor avance consiste en descubrir que una regla estaba mal planteada antes de escribir una sola línea.
Cuando piensas en algoritmos de esta manera, la palabra deja de sonar como algo reservado para especialistas. Tampoco se vuelve sinónimo de cualquier hábito. Se refiere a una forma de describir soluciones con pasos, decisiones y criterios suficientemente claros para que el procedimiento pueda repetirse y analizarse.
La próxima vez que reorganices una ruta porque una calle está cerrada, ordenes tareas según horarios o cambies la estrategia con la que buscas algo, no estarás ejecutando un programa. Sin embargo, estarás trabajando con el mismo tipo de preguntas que después aparecen al diseñar uno: qué información tengo, qué regla aplico, qué paso sigue y cuándo considero que el problema está resuelto.
Martin Rojas es especialista en tecnología y trabaja con herramientas digitales, computadoras, Internet y software desde hace muchos años. A lo largo de su trayectoria ha realizado cursos de actualización y desarrollado experiencia práctica con diferentes plataformas, sistemas y soluciones digitales. En Skydutz, transforma ese conocimiento técnico en explicaciones claras para estudiantes, profesionales y personas que quieren entender mejor la tecnología que utilizan todos los días.