Cada recorrido agrupa los mismos temas centrales —código, aplicaciones y sistemas digitales— pero cambia el punto de partida, la profundidad y el tipo de práctica. Elige según lo que ya sabes hacer y según el tiempo que puedas sostener.
Pensado para quien nunca escribió código o lo dejó hace tiempo. Se trabaja con variables, condicionales, bucles y funciones usando ejemplos cortos que puedes ejecutar y modificar. Buena parte del tiempo se dedica a leer mensajes de error y a corregir código ajeno antes de escribir el propio. El ritmo es pausado y conviene repetir cada bloque antes de avanzar.
Ver el detalle de este recorridoPara quien ya maneja lo básico y quiere entender cómo se organiza un proyecto que crece. El eje está en separar interfaz, lógica de negocio y acceso a datos, y en reconocer cuándo esa separación se rompe. Se revisan estructuras de carpetas, responsabilidades de cada capa y criterios para decidir dónde vive cada pieza del código.
Consultar el enfoque de este móduloUn recorrido más conceptual, útil si te interesa el panorama completo y no solo el código. Se presentan las capas habituales —cliente, red, servidor y persistencia— y las tensiones que aparecen al diseñar: latencia, disponibilidad y consistencia. No se entra en detalles de proveedor ni en configuraciones concretas, sino en cómo se conectan las piezas.
Revisar el temario de sistemasLos tres bloques anteriores en secuencia, para quien prefiere una sola línea de trabajo sin decidir entre ellos. Empieza por los fundamentos, sigue con la arquitectura de aplicaciones y termina en el panorama de sistemas. Exige más constancia, porque cada etapa se apoya en la anterior y conviene no saltearse tramos.
Escribir para orientar la inscripciónLa plataforma se apoya en módulos que van de la lectura de código a la comprensión de sistemas completos. Cada punto de valor responde a una pregunta concreta que aparece cuando alguien intenta aprender ingeniería de software por su cuenta.
Los módulos de fundamentos parten de problemas cortos: variables, condicionales, bucles y funciones. La idea es que el estudiante aprenda a dividir un enunciado en pasos antes de tocar el teclado, en lugar de memorizar sintaxis sin contexto.
Buena parte del trabajo real consiste en entender lo que otra persona escribió. Por eso los ejemplos se presentan primero para leerlos, después para corregirlos y solo al final para reescribirlos desde cero. Es un ritmo incómodo al principio, pero sostenible.
El desarrollo de aplicaciones se aborda mostrando por qué mezclar responsabilidades vuelve el código difícil de mantener. La separación entre capa de presentación, lógica de negocio y acceso a datos se explica con la estructura de carpetas a la vista, no como teoría abstracta.
Los sistemas digitales se presentan como capas conectadas: cliente, red, servidor y persistencia. Reconocer qué hace cada una permite leer un diagrama de arquitectura o entender una oferta técnica sin perderse en el vocabulario.
Un mensaje del compilador o del intérprete no es un castigo: es una pista. Los módulos insisten en leer el error completo antes de buscar la solución, porque esa costumbre ahorra tiempo durante años de trabajo con código.
El contenido se organiza por módulos y no por promesas de resultado. No hay certificaciones, plazos ni seguimiento automático: el avance depende de cuánto se practique con los ejemplos y de la curiosidad por entender qué hay detrás de cada pieza.
Lo que se trabaja dentro de cada módulo
La plataforma no vende atajos: ordena el recorrido en piezas concretas. Cada bloque de aprendizaje tiene un objeto claro y se apoya en ejemplos que el estudiante puede leer, ejecutar y modificar antes de pasar al siguiente nivel.
Variables, condicionales, bucles y funciones con ejemplos cortos. El trabajo empieza por leer código ajeno, corregirlo y recién después escribirlo desde cero. Interpretar un mensaje de error es parte del ejercicio, no un accidente.
La aplicación se arma separando interfaz, lógica de negocio y acceso a datos. Esa división se refleja en la estructura de carpetas y en las decisiones sobre dónde vive cada responsabilidad cuando el proyecto crece.
Cliente, red, servidor y persistencia como piezas conectadas. Se revisan latencia, disponibilidad y consistencia como tensiones de diseño, sin prometer una solución única para todos los escenarios.
Hábitos de trabajo aplicados al día a día: nombrar, ordenar, comentar lo justo y revisar antes de agregar. El objetivo es que el código se pueda tocar más adelante sin romper otras partes.
Temas que aparecen en cualquier proyecto: estructuras de datos básicas, manejo de errores y criterios para evaluar el propio código. Se explican con vocabulario común para reconocerlos en un diagrama o en una descripción de tarea.