Pensar como un programador: descomponer problemas y lógica

Lo más importante no es el código

Voy a empezar la serie de Fundamentos de programación con una afirmación que sorprende a todo el que empieza: aprender a programar no va de aprender a programar.

Me explico. Cuando alguien dice “quiero aprender a programar”, casi siempre se imagina memorizando comandos raros, símbolos y palabras en inglés. Y sí, eso existe, pero es la parte fácil. La sintaxis de un lenguaje se aprende en una tarde con la documentación abierta al lado. Lo que de verdad cuesta, y lo que de verdad separa a quien programa de quien no, es pensar como un programador.

¿Y qué es pensar como un programador? Es coger un problema, por grande y confuso que sea, y partirlo en pasos tan pequeños, tan ordenados y tan claros que una máquina absolutamente tonta pueda ejecutarlos uno detrás de otro sin equivocarse. Esta primera entrega va de eso. Sin código todavía. Solo cabeza.

El ordenador es tonto (y eso es bueno saberlo)

Tienes que meterte una idea en la cabeza desde el minuto uno: el ordenador no piensa. No tiene sentido común, no intuye lo que quieres, no rellena los huecos. Hace exactamente lo que le dices, en el orden que se lo dices, ni más ni menos. Si te dejas un paso, no lo adivina: falla.

Esto, que parece una limitación, es justo lo que hace que programar se pueda aprender. Como la máquina no improvisa, tu trabajo es no dejarte nada. Y para no dejarte nada, primero tienes que ser capaz de ver todos los pasos. Ahí entra la descomposición.

Descomponer: el ejemplo del café

Imagina que tienes que explicarle a un robot recién llegado de otro planeta cómo prepararte un café. Un robot que no sabe absolutamente nada. “Hazme un café” no le sirve de nada. Hay que bajar al detalle:

1. Ve a la cocina.
2. Coge una taza del armario.
3. Pon la taza bajo la cafetera.
4. Comprueba si hay agua en el depósito.
5. Si no hay agua, llénalo.
6. Comprueba si hay café.
7. Si no hay café, pon una cápsula.
8. Pulsa el botón de encendido.
9. Espera a que la taza esté llena.
10. Apaga la cafetera.

Eso es descomponer: convertir una orden vaga (“hazme un café”) en una secuencia de pasos concretos y ordenados. Y fíjate en algo: ya han aparecido, sin pretenderlo, conceptos que veremos en toda la serie. Los pasos 4 y 6 son comprobaciones (condiciones: ¿hay agua? ¿hay café?). El paso 9, “espera a que la taza esté llena”, es un bucle: repite “mira la taza” hasta que se cumpla algo. Programar es esto, pero con la máquina en lugar del robot.

La clave es que si sabes explicar un proceso paso a paso a otra persona, ya sabes la mitad de programar. La otra mitad es escribirlo en un idioma que la máquina entienda. Y eso viene después.

Pseudocódigo: pensar sin sintaxis

Antes de escribir en un lenguaje real, los programadores usamos algo intermedio entre el español y el código: el pseudocódigo. Es escribir la lógica en lenguaje casi humano, sin preocuparte de la sintaxis exacta de ningún lenguaje. Sirve para pensar.

El café de antes, en pseudocódigo, sería algo así:

INICIO
  coger taza
  poner taza bajo la cafetera
  SI no hay agua ENTONCES
    llenar deposito
  FIN SI
  SI no hay cafe ENTONCES
    poner capsula
  FIN SI
  encender cafetera
  MIENTRAS taza no este llena
    esperar
  FIN MIENTRAS
  apagar cafetera
FIN

No es Python, no es JavaScript, no es ningún lenguaje. Es tu idea, ordenada. El pseudocódigo no se ejecuta en ningún ordenador, pero es la herramienta más potente que tienes para pensar un problema antes de pelearte con la sintaxis. Yo, después de treinta años, lo sigo usando para los problemas difíciles. Primero pienso la lógica en pseudocódigo. Luego la traduzco.

Diagramas de flujo: dibujar la lógica

Si lo tuyo es más visual, existe otra herramienta: el diagrama de flujo. Es dibujar el proceso con cajas y flechas, y tiene una convención muy sencilla:

• Un óvalo marca el inicio y el final.
• Un rectángulo es una acción (“encender cafetera”).
• Un rombo es una decisión, una pregunta de sí o no (“¿hay agua?”), de la que salen dos caminos.
• Las flechas marcan el orden en que se recorre todo.

Dibujar el problema antes de programarlo te obliga a ver los caminos: qué pasa si sí, qué pasa si no, dónde se vuelve atrás. Para un principiante, un diagrama de flujo en una servilleta vale más que mil tutoriales. Lo dibujas, lo sigues con el dedo, y ves si tu lógica tiene sentido o se queda coja.

Lógica: el mundo es verdadero o falso

Toda la toma de decisiones de un programa se reduce a una cosa: preguntas cuya respuesta solo puede ser verdadero o falso. No hay “quizás”. A esto se le llama lógica booleana, en honor a George Boole, y es el corazón de cómo decide un ordenador.

“¿Hay agua en el depósito?” Verdadero o falso. “¿La taza está llena?” Verdadero o falso. “¿El usuario tiene más de 18 años?” Verdadero o falso. Cada decisión que toma un programa es, en el fondo, evaluar una de estas preguntas y actuar según la respuesta.

Y estas preguntas se pueden combinar con tres operaciones que conviene tener claras desde ya:

• Y (AND): verdadero solo si las dos cosas son verdad. “¿Hay agua Y hay café?” Si falta cualquiera de las dos, no hay café.
• O (OR): verdadero si al menos una es verdad. “¿Es sábado O es domingo?” Con que se cumpla una, es fin de semana.
• NO (NOT): le da la vuelta. “¿NO hay agua?” es verdadero justo cuando no la hay.

Esto que parece de cajón es, literalmente, sobre lo que se construye todo el software del planeta. Lo veremos a fondo cuando lleguemos a los operadores y al control de flujo, pero quédate con la idea: el ordenador decide respondiendo preguntas de sí o no.

Abstracción: olvidarte de los detalles

Hay un último concepto para hoy, y es de los que distinguen a quien piensa bien: la abstracción. Suena pomposo, pero es de lo más natural del mundo.

Cuando conduces un coche, giras el volante y el coche gira. No piensas en la cremallera de dirección, ni en la presión hidráulica, ni en cómo se transmite la fuerza a las ruedas. El volante te esconde toda esa complejidad y te da una orden simple: “girar”. Eso es abstracción: usar algo por lo que hace, sin necesitar saber cómo lo hace por dentro.

En programación pasa igual. Cuando tengas “hacer café” resuelto y bien empaquetado, podrás usarlo sin volver a pensar en los diez pasos. Lo llamas y ya está. Esa capacidad de esconder lo complejo detrás de algo simple es lo que te permite construir cosas grandes sin volverte loco, y es la base de las funciones que veremos más adelante.

Lo siguiente: dónde guarda las cosas el programa

Hoy no hemos escrito código de verdad, y ha sido a propósito. Si te llevas una sola idea, que sea esta: programar es pensar, descomponer y ordenar. La sintaxis es lo de menos, llega sola.

En la próxima entrega bajamos un escalón hacia el código real y empezamos por lo más básico de todo: las variables y los tipos de datos, es decir, dónde y cómo guarda un programa la información con la que trabaja. Porque para hacer el café, primero hay que saber dónde dejamos la taza.

Preguntas frecuentes

¿Hace falta ser bueno en matemáticas para programar?

No tanto como cree la gente. Para la programación del día a día basta con lógica y aritmética básica. Lo que de verdad importa es la capacidad de descomponer problemas y razonar paso a paso, que es lo que enseña esta entrega. Las matemáticas avanzadas solo hacen falta en campos muy concretos, como los gráficos 3D o la Inteligencia Artificial.

¿Qué es el pseudocódigo y por qué se usa?

El pseudocódigo es escribir la lógica de un programa en lenguaje casi humano, sin la sintaxis exacta de ningún lenguaje real. No se ejecuta en un ordenador: sirve para pensar y diseñar la solución antes de traducirla a código. Es la mejor herramienta para razonar un problema sin atascarte en los detalles de un lenguaje.

¿Por dónde empiezo si nunca he programado?

Por aquí. Esta es la primera entrega de la serie de Fundamentos y no asume ningún conocimiento previo. Léela, practica descomponiendo procesos cotidianos en pasos (como el ejemplo del café) y sigue con la siguiente entrega sobre variables. La serie está diseñada para recorrerse en orden desde el cero absoluto.

El libro para esta entrega

Si esta entrega te ha encajado y quieres un libro en español que te lleve de la mano desde este pensamiento hasta tu primer programa, el mejor para empezar de cero es Python para principiantes, de Daniel Correa y Paola Vallejo. Arranca justo por aquí, por la lógica y los algoritmos, antes de tocar nada de código serio. De toda la lista que dejé en el índice, es el que mejor pega para arrancar.

Este artículo contiene enlaces de afiliado.

Compártelo si te ha resultado útil.

¿Cuál es el primer proceso cotidiano que se te ocurre descomponer en pasos, al estilo del café? Cuéntamelo en los comentarios.

Y… la próxima semana, por fin, código.