En una aplicación ya existe un botón para registrar alumnos. Un día aparece una solicitud aparentemente sencilla: después de guardar el registro, el sistema también debe enviar un correo de confirmación. Desde fuera, parece una modificación pequeña. Hay un botón, existe una dirección de correo y solo falta “hacer que mande el mensaje”.
Para quien programa, la tarea empieza bastante antes de escribir la instrucción que envía ese correo. Hay que entender cuándo debe salir, qué ocurre si la dirección está mal escrita, cómo evitar que se envíe dos veces, qué servicio realizará el envío, qué mensaje verá el usuario si algo falla y cómo comprobar que la nueva función no rompió el registro que ya funcionaba.
Ese recorrido explica mejor qué es programar que la imagen clásica de alguien escribiendo líneas de código durante horas. El código importa, pero constituye una parte de un proceso más amplio: comprender un problema con suficiente precisión para convertirlo en instrucciones, organizar esas instrucciones y comprobar qué sucede cuando la computadora las ejecuta.
Programar empieza con un problema que todavía no está expresado para una computadora
Las personas solemos dar instrucciones apoyándonos en contexto.
Podemos decirle a alguien “registra al alumno y avísale por correo” y confiar en que interpretará muchas cosas por cuenta propia. Una computadora necesita reglas mucho más explícitas: qué datos forman un registro válido, qué campo contiene el correo, qué sucede cuando falta información, cuándo se considera terminado el proceso y qué hacer ante un error.
La Dirección General de Cómputo y de Tecnologías de Información y Comunicación de la UNAM plantea en su curso de Introducción a la programación la solución de problemas mediante dos aprendizajes relacionados: construir algoritmos capaces de representar una solución y expresar después esos algoritmos mediante un lenguaje de programación.
Esa separación es útil para un principiante porque muestra que programar no empieza necesariamente por memorizar palabras como if, for o print.
Primero necesitas saber qué quieres que ocurra.
Un algoritmo puede entenderse, en este contexto, como una manera ordenada de representar los pasos y decisiones necesarios para llegar a un resultado. La UNAM explica en su recurso educativo sobre sistematización de algoritmos que un problema puede dividirse en partes más sencillas y que un algoritmo puede transformarse posteriormente en un programa escrito en un lenguaje de programación.
Así, una idea humana comienza a adquirir suficiente detalle para que pueda convertirse en software.
El trabajo real aparece entre “quiero esta función” y “ya funciona”
Volvamos al correo de confirmación.
Antes de tocar el código, un programador necesita entender el sistema existente. Tal vez los alumnos se registran desde una página web. Quizá los registros llegan también desde una aplicación móvil. Puede existir una base de datos compartida con otro sistema administrativo.
Cambiar algo sin conocer ese contexto puede resolver una pantalla y crear un problema en otra.
El programador suele comenzar leyendo. Revisa código que otra persona escribió, documentación, estructura del proyecto, nombres de archivos, configuraciones y datos utilizados por la aplicación. En equipos grandes puede conversar con diseñadores, responsables de producto, personal de soporte, analistas, especialistas en bases de datos o con otros desarrolladores.
Después llega una decisión: ¿en qué parte del sistema pertenece la nueva función?
Enviar el correo directamente desde el botón quizá funcione en una aplicación pequeña. En otro sistema puede ser preferible registrar primero al alumno, guardar una tarea pendiente y permitir que otro servicio procese el envío. La mejor solución depende de la arquitectura, el volumen de usuarios y las consecuencias de un fallo.
En ese punto aparece el código.
Un lenguaje de programación ofrece reglas y estructuras para expresar lo que el sistema debe hacer. Python, JavaScript, Java, C#, C++ y muchos otros permiten escribir programas, aunque cada uno tenga sintaxis, herramientas y ámbitos de uso diferentes. El glosario de MDN sobre programación de computadoras describe la programación como el proceso de componer y organizar instrucciones que indican a una computadora o software qué hacer.
Escribir esas instrucciones exige bastante precisión.
Quizá el programa debe comprobar que existe una dirección de correo válida. Después genera un mensaje, intenta enviarlo y registra el resultado. Si el servicio de correo no responde, la aplicación necesita decidir si vuelve a intentarlo, informa del problema o continúa sin bloquear el registro del alumno.
El primer intento rara vez cubre todas las situaciones.
Entonces empieza otra parte cotidiana del trabajo: probar.
El programador ejecuta el cambio con distintos datos, provoca errores deliberadamente, revisa resultados y observa qué ocurre en condiciones menos cómodas. ¿Qué pasa con un correo vacío? ¿Y con un alumno que ya estaba registrado? ¿Qué sucede cuando el servicio externo tarda demasiado?
Cuando el comportamiento no coincide con lo esperado, empieza la depuración.
Depurar significa localizar la causa de un fallo y corregirla. A veces el error está exactamente donde aparece. Otras veces la pantalla muestra un problema cuyo origen se encuentra varias capas atrás: un dato incorrecto, una condición mal planteada, una comunicación fallida con otro servicio o una suposición equivocada sobre el sistema.
Resolverlo implica formular hipótesis, observar información y descartar causas.
En proyectos reales, el código de una persona suele ser revisado por alguien más antes de incorporarse a la aplicación principal. Esa revisión puede detectar errores, inconsistencias o una solución difícil de mantener en el futuro.
Después vienen pruebas adicionales y, finalmente, la publicación del cambio.
Incluso ahí el trabajo puede continuar. Una función que pasó correctamente las pruebas puede comportarse de otra manera cuando miles de usuarios la utilizan o cuando interactúa con datos que el equipo no había previsto.
Programar incluye escribir código, pero buena parte del oficio ocurre alrededor de él.
Lo que ve el usuario ocupa solo una parte del trabajo
Cuando utilizas una aplicación, normalmente juzgas el resultado final. Tocaste un botón y algo ocurrió.
Detrás de esa acción existen decisiones que permanecen invisibles mientras funcionan correctamente.
| Lo que observa el usuario | Parte del trabajo del programador |
|---|---|
| Un formulario guarda datos | Validación, almacenamiento, manejo de errores y seguridad |
| Una página carga información | Comunicación con servidores, datos, tiempos de respuesta y estados de carga |
| Un botón realiza una acción | Reglas, condiciones, eventos y respuesta ante fallos |
| Una cuenta mantiene una sesión | Identificación, permisos, almacenamiento y mecanismos de autenticación |
| Una nueva función aparece en la app | Análisis, código, pruebas, revisión, despliegue y mantenimiento |
Esta diferencia ayuda a entender por qué dos programas que parecen hacer lo mismo pueden ser muy distintos por dentro.
Un ejercicio para convertir temperaturas puede resolverse con unas cuantas instrucciones. Una aplicación utilizada por miles de personas necesita considerar simultáneamente datos, interfaz, servidores, seguridad, rendimiento, compatibilidad y mantenimiento.
Por eso tampoco existe un único tipo de programador.
Algunos trabajan principalmente con aquello que aparece en el navegador; otros desarrollan servicios que procesan información detrás de la pantalla. Hay profesionales especializados en aplicaciones móviles, videojuegos, datos, sistemas integrados en dispositivos, automatización, infraestructura, pruebas o herramientas internas de una empresa.
Las tareas cambian, pero varios hábitos sobreviven al cambio de tecnología: leer sistemas existentes, dividir problemas, representar datos, escribir instrucciones, comprobar comportamientos y corregir errores.
Microsoft ofrece en su ruta de aprendizaje de conceptos básicos de los equipos informáticos una introducción para principiantes que conecta el funcionamiento de las computadoras con la historia y evolución del desarrollo de aplicaciones. Esa relación importa: el software que escribimos termina ejecutándose sobre hardware, sistemas operativos, redes y otros programas.
Ya vimos en Skydutz cómo funciona una computadora desde que la enciendes. Programar agrega otra capa a esa historia. En lugar de limitarte a usar las instrucciones que otros prepararon, empiezas a construir parte del comportamiento que la máquina ejecutará.
Aprender a programar cambia cuando dejas de perseguir únicamente la sintaxis
Es normal que el primer contacto con programación se concentre en palabras nuevas.
Una variable guarda un valor. Una condición permite decidir. Un ciclo repite una tarea. Una función agrupa instrucciones. Todo eso será importante y aparecerá en los próximos artículos de esta categoría.
El problema surge cuando aprender programación se convierte exclusivamente en recordar cómo escribir esas estructuras en un lenguaje determinado.
Puedes memorizar la sintaxis de un ciclo y todavía no reconocer cuándo necesitas repetir algo. Puedes aprender a declarar veinte tipos de variables y seguir teniendo dificultades para representar los datos de un problema sencillo.
La práctica empieza a cambiar cuando el código responde a una necesidad concreta.
Piensa en una pequeña aplicación que calcula cuánto has gastado durante la semana. Antes de elegir un lenguaje, ya aparecen preguntas útiles: ¿qué datos necesita recibir?, ¿cómo representará cada gasto?, ¿qué debe sumar?, ¿qué ocurre cuando todavía no hay registros?, ¿qué resultado tiene que mostrar?
Después puedes traducir esas decisiones al lenguaje que estés aprendiendo.
Ese orden evita una frustración común: creer que programar consiste en recordar cada comando disponible. Los programadores consultan documentación, buscan cómo funciona una biblioteca, revisan ejemplos y vuelven a leer código que no recuerdan con exactitud. Conocer los fundamentos permite entender lo que encuentras y decidir cómo utilizarlo.
Incluso la experiencia profesional no elimina la investigación. Cambian las preguntas.
Al principio buscas cómo escribir una condición. Más adelante quizá investigues por qué una consulta tarda demasiado, cómo integrar un servicio externo o qué comportamiento tiene una herramienta en determinada versión.
La capacidad valiosa no es tener todas las respuestas almacenadas en la memoria.
Es poder llevar un problema desde una descripción todavía ambigua hasta algo que puedas representar, ejecutar, observar y corregir.
El código aparece en medio de ese recorrido.
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.