Cómo aprender a programar desde cero en 2026: la guía completa

Para aprender a programar desde cero en 2026 necesitas tres cosas: un lenguaje (Python es la mejor apuesta para la mayoría), unas 10 horas semanales durante unos 12 meses, y un protocolo estricto para usar la IA sin que aprenda ella en tu lugar. Lo demás —el bootcamp, el máster, el lenguaje de moda— es opcional. Esto no.

Esta guía está escrita desde el otro lado de la mesa: no vendo un curso, vivo de programar. Y eso cambia lo que te voy a contar, empezando por la parte incómoda de la que casi nadie escribe: el mercado junior de 2026 no se parece al de 2021, y el modo en que aprendiste a estudiar —ver tutoriales, copiar, sentir que avanzas— es exactamente el que hoy te deja fuera.

La buena noticia es que el camino sigue existiendo y es más corto que nunca. Solo que hay que recorrerlo de otra manera.

Índice de lo que vas a encontrar

Es una guía larga a propósito: está pensada para que la vuelvas a abrir dentro de tres meses, no para leerla de un tirón. Estas son las paradas:

1. ¿Sigue valiendo la pena en 2026? — los datos, sin adornos
2. Qué es programar de verdad — y los 6 mitos que te frenan
3. Qué lenguaje elegir
4. Monta tu entorno en 30 minutos
5. Los 9 conceptos que son el 90 % de programar
6. Tu primer programa útil, línea por línea
7. Depurar: la habilidad que separa a los que siguen
8. Git y GitHub: lo mínimo imprescindible
9. Cómo usar la IA sin dejar de aprender — el capítulo clave
10. La ruta de 12 meses, mes a mes
11. Los 7 proyectos que sí importan
12. Cómo no abandonar
13. Del portafolio al primer trabajo
14. Recursos gratis que valen la pena
15. Los errores que matan el 90 % de los intentos

---

¿Sigue valiendo la pena aprender a programar en 2026?

Sí, pero la respuesta honesta necesita dos párrafos, no uno.

La parte mala primero. La contratación de perfiles junior se ha desplomado. Según el State of Tech Talent Report 2026 de SignalFire, la contratación de recién egresados cayó alrededor de un 65 % en las grandes tecnológicas y un 76 % en startups de fase temprana respecto a 2019. El informe es explícito sobre el motivo:

Los egresados de ingeniería de software solían pasar sus primeros 12 a 18 meses escribiendo código repetitivo, ejecutando tests unitarios y depurando cosas rutinarias mientras aprendían los sistemas de producción con un mentor. Esas son exactamente las tareas que las grandes tecnológicas han automatizado con IA.

Ahí está el problema real, y conviene entenderlo bien: la IA no eliminó los trabajos de programador, eliminó el andamio con el que se formaban los programadores. El primer peldaño de la escalera es el que se rompió.

Y ahora la parte buena, que es más grande. Ese mismo informe cuenta que los mejores egresados tienen hoy el doble de probabilidades de llamarse founder que la promoción de 2022, porque con las herramientas de 2026 una persona sola construye lo que antes pedía un equipo. Y en el mercado real —el que no son las cinco grandes tecnológicas— la demanda no ha desaparecido: se ha desplazado.

Lo que hoy no encuentra quien contrata es alguien que:

• entienda un sistema entero y sepa dónde tocarlo sin romperlo,
• sepa revisar código generado por IA y detectar cuándo está mal,
• pueda entregar una funcionalidad completa (base de datos, lógica, interfaz, despliegue) en vez de una función suelta,
• y traduzca un problema de negocio a algo que se pueda construir.

Nada de eso lo hace un modelo de lenguaje hoy. Todo eso se aprende programando.

💡 El resumen en una frase. Ya no se contrata a alguien para que escriba código. Se contrata a alguien que responda por el código. Y para responder por él, hay que entenderlo.

El dato que casi nadie pone junto al anterior

Mientras la contratación junior caía, la producción de software se disparó. La consecuencia es que hay mucho más código, escrito más rápido y peor mantenido que nunca. La investigación de GitClear sobre calidad de código con IA, basada en más de 600 millones de commits, mide exactamente eso:

Traducido: se copia y pega ocho veces más, se refactoriza cinco veces menos y el código se tira a la basura al doble de velocidad. Eso es deuda técnica acumulándose a un ritmo histórico, y alguien va a tener que entenderla y arreglarla.

Ese alguien puedes ser tú. Pero solo si sabes leer código, no solo generarlo.

---

Qué es programar de verdad (y qué no es)

Antes de instalar nada, el modelo mental. Programar es describirle a una máquina, sin ambigüedad, cómo transformar unos datos de entrada en un resultado. Nada más. Todo lo demás —lenguajes, frameworks, la nube— son capas encima de esa idea.

Y esa descripción sin ambigüedad solo tiene tres ingredientes:

graph TB
    A[Datos de entrada] --> B{¿Decisión?}
    B -->|sí| C[Hacer una cosa]
    B -->|no| D[Hacer otra]
    C --> E[Repetir mientras haga falta]
    D --> E
    E --> F[Resultado]

1. Guardar datos — variables y estructuras (una lista de precios, un diccionario de usuarios).
2. Tomar decisiones — si pasa esto, haz aquello.
3. Repetir — haz esto para cada elemento de la lista.

Eso es todo. Un sistema bancario y un juego son combinaciones enormes de esos tres ladrillos. Cuando alguien lleva veinte años programando, lo que tiene no son más ladrillos: tiene mejores criterios para ordenarlos.

Los 6 mitos que frenan a la gente en la línea de salida

«Hay que ser bueno en matemáticas.» Falso para el 95 % del trabajo. Programar aplicaciones web, sistemas de gestión, apps móviles o automatizaciones requiere aritmética de secundaria y lógica, que es otra cosa. Sí necesitas matemáticas de verdad para gráficos 3D, criptografía, machine learning desde los cimientos o simulaciones científicas. Ninguna de esas es tu primer trabajo.

«Hay que saber inglés.» Ayuda mucho y conviene aprenderlo en paralelo, pero ya no es un muro. La documentación se traduce sola, los errores se pueden pegar en un chat y pedir explicación en español, y las palabras clave de los lenguajes son unas treinta. Aprende a leer inglés técnico; no esperes a hablarlo.

«Ya soy mayor.» El sesgo por edad en tecnología existe, no te voy a mentir. Pero un cambio de carrera a los 35 o los 45 llega con algo que un chico de 20 no tiene: entiendes cómo funciona una empresa, sabes hablar con un cliente y ya has visto proyectos fracasar. Eso es exactamente lo que falta en los equipos junior.

«Necesito una computadora potente.» Cualquier equipo de los últimos ocho años con 8 GB de RAM sirve para todo lo de esta guía. Se necesita máquina buena para editar vídeo, entrenar modelos o compilar proyectos gigantes. Para aprender, no.

«Necesito un título.» Ayuda a pasar el filtro de RR. HH. de empresas grandes. No lo necesitas para la PyME, la agencia, el freelance o la startup, que es de donde salen casi todos los primeros trabajos. Lo que sí necesitas es evidencia: código público que funcione.

«Es demasiado tarde, la IA ya lo hace todo.» La IA escribe funciones. No decide qué hay que construir, no responde ante un cliente, no entiende por qué el negocio factura como factura, y —según los propios desarrolladores— acierta a medias: en la encuesta de Stack Overflow 2025, la queja número uno, con un 66 %, fue toparse con «soluciones de IA que están casi bien, pero no del todo». Y otro 45 % añade que depurar código generado por IA le consume más tiempo.

Alguien tiene que darse cuenta de dónde está el casi.

---

La decisión que te bloquea: qué lenguaje elegir

Aquí es donde se atasca la mitad de la gente durante semanas. Voy a quitarte la decisión de encima:

👉 Empieza con Python. Punto. Si al terminar esta guía descubres que lo tuyo es el desarrollo web de interfaces, cambia a JavaScript en la semana 12 y te habrá costado cero: el 90 % de lo que aprendiste se transfiere íntegro.

Por qué Python y no otro

Python es el número 1 del índice TIOBE de agosto de 2026 con un 18,53 %, muy por delante del segundo. Pero la popularidad no es la razón. Las razones son estas:

• Se lee casi como inglés. if edad >= 18: print("mayor"). No hay llaves, ni punto y coma, ni tipos que declarar. Cada símbolo que no tienes que aprender es energía que va a la lógica, que es lo difícil.
• El error te dice qué pasó. Los mensajes de error de Python son de los más legibles que existen, y aprender a leerlos es media batalla.
• Sirve para todo lo que probablemente quieras hacer: automatizar tareas aburridas, analizar datos, construir APIs, scrapear webs, y absolutamente todo lo relacionado con IA.
• La salida laboral no es solo “programador”: analista de datos, automatización, QA, DevOps y científico de datos también piden Python.

Cuándo NO empezar con Python

Y JavaScript, ¿cuándo?

JavaScript es el segundo lenguaje que vas a aprender casi con seguridad, porque es el único que se ejecuta dentro del navegador: si quieres que algo se vea y se pueda tocar en una web, pasa por ahí. En esta guía voy a poner el equivalente en JavaScript de los ejemplos clave, marcado como opcional, para que veas con tus ojos que la lógica es la misma y solo cambia la puntuación.

No estudies los dos a la vez. Míralos en paralelo cuando aparezcan, y elige uno para practicar.

⚠️ La trampa del lenguaje de moda. Cada año hay un lenguaje que «va a reemplazar a todos» —Rust, Go, Zig, Mojo—. Todos son buenos y ninguno es tu primer lenguaje: sus comunidades asumen que ya programas. Rust entró al top 10 de TIOBE en julio de 2026 y es magnífico; también es probablemente el peor lenguaje del mundo para aprender a programar.

---

Monta tu entorno en 30 minutos

Objetivo: escribir código y ejecutarlo. No necesitas nada más y todo es gratis.

Opción A — Sin instalar nada (5 minutos)

Si quieres escribir tu primera línea hoy, ve a replit.com o a Google Colab y crea un cuaderno de Python. Funciona hasta en el móvil.

Úsalo la primera semana. Después instala Python de verdad: aprender a manejar tu propia máquina es parte del trabajo, y en una entrevista se nota quién nunca salió del navegador.

Opción B — La instalación real (30 minutos)

Paso 1. Instala Python. La versión estable en agosto de 2026 es Python 3.14 (3.14.7 desde el 5 de agosto). La 3.15 llega en octubre; no la esperes.

# Windows (desde PowerShell)
winget install Python.Python.3.14

# macOS (con Homebrew)
brew install [email protected]

# Ubuntu / Debian / WSL
sudo apt update && sudo apt install python3 python3-pip python3-venv

⚠️ Windows: si instalas desde el .exe de python.org en vez de con winget, marca la casilla «Add python.exe to PATH» en la primera pantalla. Es la causa del 90 % de los python no se reconoce como un comando que verás en foros.

Comprueba que funcionó:

python --version
# Python 3.14.7

Paso 2. Instala VS Code. Es el editor gratuito de Microsoft y es el estándar de facto. Descárgalo de code.visualstudio.com e instala solo dos extensiones para empezar: Python (de Microsoft) y Error Lens (te enseña el error en la propia línea, sin abrir un panel).

No instales veinte extensiones el primer día. Si más adelante quieres afinar el editor, tengo una lista comentada en las 20 mejores extensiones de VS Code.

Paso 3. Aprende cinco comandos de terminal. La terminal da miedo hasta que descubres que el 95 % del uso diario son estos:

pwd          # ¿dónde estoy?
ls           # ¿qué hay aquí?  (en PowerShell: dir)
cd carpeta   # entra a una carpeta
cd ..        # sube un nivel
mkdir nombre # crea una carpeta

Paso 4. Crea tu carpeta de trabajo y tu primer archivo.

mkdir aprendiendo && cd aprendiendo
code .

Dentro de VS Code crea hola.py con esto:

nombre = input("¿Cómo te llamas? ")
print(f"Hola, {nombre}. Acabas de programar.")

Y ejecútalo desde la terminal integrada (Ctrl+ñ o `Ctrl+“):

python hola.py

Si te respondió, tu entorno está listo. En serio: eso es todo lo que necesitas durante los próximos seis meses.

Lo mismo en JavaScript (opcional — sáltatelo si vas con Python)

Necesitas Node.js instalado. El archivo sería hola.js:

const readline = require('node:readline/promises');
const rl = readline.createInterface({ input: process.stdin, output: process.stdout });

const nombre = await rl.question('¿Cómo te llamas? ');
console.log(`Hola, ${nombre}. Acabas de programar.`);
rl.close();

Y se ejecuta con node hola.js. Fíjate en lo que cambia: llaves, punto y coma, y bastante más ceremonia para leer una línea de texto. Por eso empezamos con Python.

Los entornos virtuales, explicados de una vez

En cuanto instales tu primera librería vas a leer sobre venv y nadie te explicará por qué. Es simple: un entorno virtual es una mochila de librerías que pertenece solo a un proyecto. Sin él, todos tus proyectos comparten las mismas versiones y el día que uno necesite una versión distinta, rompes los otros.

python -m venv .venv           # crear la mochila
source .venv/bin/activate      # ponértela (macOS/Linux)
.venv\Scripts\activate         # ponértela (Windows)
pip install requests           # instalar algo dentro
deactivate                     # quitártela

Regla: una carpeta de proyecto, un .venv. Créalo siempre, aunque el proyecto sea de diez líneas. Es un hábito de tres segundos que evita tardes enteras de dolor.

---

Los 9 conceptos que son el 90 % de programar

Si dominas estos nueve, puedes leer casi cualquier programa del mundo. Todo lo demás son variaciones y librerías.

Dedícales entre cuatro y seis semanas. No los leas: escríbelos. Cada bloque de código de esta sección debes teclearlo tú —no copiarlo— y romperlo a propósito para ver qué error sale.

1. Variables: cajas con nombre

Una variable es un nombre que apunta a un valor. Se escribe con =.

nombre = "Ana"
edad = 34
altura = 1.68
es_cliente = True

Python deduce solo el tipo: texto (str), entero (int), decimal (float), booleano (bool). Puedes preguntárselo:

print(type(edad))     # <class 'int'>

La trampa típica: "5" + "3" da "53", no 8. El + sobre texto concatena. Si un dato viene de input() siempre es texto, aunque parezca un número:

edad = input("Tu edad: ")     # "34"  ← texto
edad = int(input("Tu edad: ")) # 34   ← número

2. Estructuras de datos: cuando una caja no basta

Las dos que usarás el 90 % del tiempo:

Listas — colecciones ordenadas, se accede por posición (empezando en 0):

precios = [120, 340, 89, 1500]
print(precios[0])      # 120
print(precios[-1])     # 1500  (la última)
print(len(precios))    # 4
precios.append(200)    # añade al final

Diccionarios — pares clave→valor, se accede por nombre:

cliente = {
    "nombre": "Ana",
    "email": "[email protected]",
    "saldo": 1500,
}
print(cliente["nombre"])          # Ana
print(cliente.get("telefono"))    # None, y no revienta
cliente["telefono"] = "555-1234"  # añadir

Cuándo usar cuál: si vas a recorrer todo, lista. Si vas a buscar por un identificador, diccionario. Buscar en un diccionario es instantáneo aunque tenga un millón de elementos; buscar en una lista obliga a recorrerla entera. Esa diferencia se llama complejidad algorítmica y es, ya, el 80 % de lo que necesitas saber del tema.

3. Condicionales: tomar decisiones

saldo = 1500

if saldo > 1000:
    print("Cliente premium")
elif saldo > 0:
    print("Cliente estándar")
else:
    print("Sin saldo")

La indentación en Python no es estética: es sintaxis. Los cuatro espacios son los que marcan qué está dentro del if. En otros lenguajes eso lo hacen las llaves.

La trampa típica: confundir = (asignar) con == (comparar). if saldo = 1000 es un error de sintaxis en Python —y, gracias a eso, un error que descubres al instante en vez de a los tres días.

Lo mismo en JavaScript (opcional)

const saldo = 1500;

if (saldo > 1000) {
  console.log("Cliente premium");
} else if (saldo > 0) {
  console.log("Cliente estándar");
} else {
  console.log("Sin saldo");
}

Idéntica lógica. Cambian los paréntesis, las llaves y elif pasa a else if. En JavaScript compara siempre con === (tres iguales), no con ==: el doble igual hace conversiones automáticas que producen sorpresas como que 0 == "0" sea verdadero.

4. Bucles: repetir sin repetirte

precios = [120, 340, 89, 1500]

for precio in precios:
    print(f"El precio es {precio}")

total = 0
for precio in precios:
    total += precio          # total = total + precio
print(f"Total: {total}")     # Total: 2049

El while repite mientras una condición se cumpla, y es donde se cuelgan los programas de los principiantes:

intentos = 0
while intentos < 3:
    print("Intentando…")
    intentos += 1            # ← si olvidas esta línea, bucle infinito

Truco de supervivencia: Ctrl+C en la terminal mata un programa colgado.

5. Funciones: empaquetar una idea

Una función es un trozo de lógica con nombre, al que le pasas datos y te devuelve un resultado.

def calcular_iva(monto, tasa=0.16):
    """Devuelve el monto con IVA incluido."""
    return monto * (1 + tasa)

print(calcular_iva(1000))        # 1160.0
print(calcular_iva(1000, 0.08))  # 1080.0  (frontera)

Tres reglas que te ahorrarán años:

1. Una función hace una cosa. Si al describirla usas un «y», son dos funciones.
2. El nombre es un verbo y dice qué hace: calcular_iva, no proceso1.
3. Devuelve, no imprimas. Una función que hace print solo sirve para mostrar en pantalla; una que hace return sirve para todo, incluido imprimirla después.

6. Errores y excepciones: que el programa no se muera

try:
    edad = int(input("Tu edad: "))
except ValueError:
    print("Eso no es un número. Uso 0.")
    edad = 0

No uses except: a secas ni except Exception: para todo. Capturar todos los errores esconde los que no esperabas, y luego pasas horas buscando un fallo que el programa se estaba tragando en silencio. Captura el error concreto que sabes que puede pasar.

7. Archivos: hablar con el mundo exterior

# leer
with open("datos.txt", encoding="utf-8") as f:
    contenido = f.read()

# escribir
with open("salida.txt", "w", encoding="utf-8") as f:
    f.write("Hola desde Python")

El with cierra el archivo solo, incluso si algo falla a mitad. Úsalo siempre.

Pon siempre encoding="utf-8". Si no, el día que un archivo traiga una ñ o un acento, el programa se cae en Windows y funciona en Mac, y vas a perder una tarde entera entendiendo por qué.

8. Módulos y librerías: no reinventar la rueda

import json                    # viene con Python
from datetime import date      # solo una parte

hoy = date.today()
print(hoy.isoformat())         # 2026-08-15

Para lo que no viene incluido, pip (con el entorno virtual activado):

pip install requests

import requests

respuesta = requests.get("https://api.github.com/users/ortamarco")
datos = respuesta.json()
print(datos["public_repos"])

Ahí acabas de consumir una API. Esas cuatro líneas son la base de una parte enorme del software moderno.

9. Clases: cuando los datos y la lógica van juntos

El último concepto, y el que puedes aplazar más. Una clase es un molde para crear objetos que llevan datos y las funciones que operan sobre esos datos.

class CuentaBancaria:
    def __init__(self, titular, saldo=0):
        self.titular = titular
        self.saldo = saldo

    def depositar(self, monto):
        if monto <= 0:
            raise ValueError("El monto debe ser positivo")
        self.saldo += monto
        return self.saldo

cuenta = CuentaBancaria("Ana", 1000)
cuenta.depositar(500)
print(cuenta.saldo)   # 1500

No necesitas dominar herencia, polimorfismo ni patrones de diseño para tu primer trabajo. Necesitas leer una clase y entender qué hace, porque todo el código profesional que vas a tocar está lleno de ellas.

✅ Prueba de que dominas los 9. Escribe, sin mirar nada, un programa que lea un archivo de texto con un nombre por línea, cuente cuántas veces aparece cada uno y guarde el resultado ordenado en otro archivo. Si te sale en menos de una hora, has terminado esta etapa.

---

Tu primer programa útil, línea por línea

Los tutoriales te hacen construir una calculadora. Vamos a construir algo que usarías de verdad: un analizador de gastos que lee un CSV exportado del banco y te dice en qué se te va el dinero.

Crea gastos.csv:

fecha,concepto,categoria,monto
2026-08-01,Supermercado,comida,1250.50
2026-08-03,Gasolina,transporte,800.00
2026-08-05,Restaurante,comida,450.75
2026-08-08,Uber,transporte,180.00
2026-08-10,Netflix,suscripciones,219.00
2026-08-12,Supermercado,comida,980.25

Y analizar.py:

import csv
from collections import defaultdict


def leer_gastos(ruta):
    """Lee el CSV y devuelve una lista de diccionarios."""
    with open(ruta, encoding="utf-8") as f:
        return list(csv.DictReader(f))


def sumar_por_categoria(gastos):
    """Devuelve {categoria: total} a partir de la lista de gastos."""
    totales = defaultdict(float)
    for gasto in gastos:
        totales[gasto["categoria"]] += float(gasto["monto"])
    return dict(totales)


def formatear_reporte(totales):
    """Convierte los totales en un texto legible, de mayor a menor."""
    gran_total = sum(totales.values())
    lineas = ["REPORTE DE GASTOS", "=" * 40]

    for categoria, monto in sorted(totales.items(), key=lambda x: -x[1]):
        porcentaje = monto / gran_total * 100
        barra = "█" * int(porcentaje / 5)
        lineas.append(f"{categoria:<15} ${monto:>9,.2f}  {porcentaje:5.1f}% {barra}")

    lineas.append("=" * 40)
    lineas.append(f"{'TOTAL':<15} ${gran_total:>9,.2f}")
    return "\n".join(lineas)


if __name__ == "__main__":
    gastos = leer_gastos("gastos.csv")
    totales = sumar_por_categoria(gastos)
    print(formatear_reporte(totales))

Ejecútalo:

python analizar.py

REPORTE DE GASTOS
========================================
comida          $ 2,681.50  73.1% ██████████████
transporte      $   980.00  26.7% █████
suscripciones   $   219.00   6.0% █
========================================
TOTAL           $ 3,880.50

Qué acabas de aprender sin darte cuenta

Este programa de 30 líneas contiene más buenas prácticas que la mayoría de tutoriales de tres horas:

Ahora rómpelo (esto es la parte importante)

Modificar código ajeno que funciona es la forma más rápida de aprender. Hazlo con este, en orden:

1. Añade una columna metodo_pago al CSV y un reporte por método.
2. Filtra: que solo sume los gastos de un mes que le pases por argumento.
3. Haz que acepte la ruta del archivo desde la línea de comandos (import sys, sys.argv[1]).
4. Que avise si una categoría se pasa del 40 % del total.
5. Exporta el reporte a un archivo en vez de imprimirlo.

Cuando las cinco te salgan, sabes programar en el sentido que le importa a alguien que contrata.

---

Depurar: la habilidad que separa a los que siguen de los que abandonan

Nadie escribe un curso llamado «cómo depurar», y sin embargo es donde vas a pasar la mitad de tu vida profesional. Es también el punto exacto en el que la gente abandona: no porque el concepto sea difícil, sino porque cree que el error significa que no sirve para esto.

No lo significa. Los errores son el mecanismo normal de trabajo. Un desarrollador con quince años de experiencia ve errores todo el día; la diferencia es que tarda treinta segundos donde tú tardas dos horas. Esa diferencia se aprende, y se aprende rápido.

Paso 1: lee el error de abajo hacia arriba

Python te lo cuenta todo. El problema es que casi nadie lo lee.

Traceback (most recent call last):
  File "/home/ana/aprendiendo/analizar.py", line 32, in <module>
    totales = sumar_por_categoria(gastos)
  File "/home/ana/aprendiendo/analizar.py", line 17, in sumar_por_categoria
    totales[gasto["categoria"]] += float(gasto["monto"])
                                   ^^^^^^^^^^^^^^^^^^^^
ValueError: could not convert string to float: '1,250.50'

Léelo así, en este orden:

1. La última línea dice qué pasó: ValueError: could not convert string to float: '1,250.50'. No se pudo convertir '1,250.50' a número.
2. El último File dice dónde: línea 17 de analizar.py.
3. La flecha ^^^^ dice exactamente qué expresión reventó.
4. Las líneas de arriba son el camino que se recorrió para llegar ahí.

Con eso ya sabes el diagnóstico completo: el CSV trae comas como separador de miles y float() no las entiende. La solución es float(gasto["monto"].replace(",", "")).

Regla: nunca pidas ayuda —ni a una persona ni a una IA— sin haber leído la última línea del error. En al menos la mitad de los casos, la respuesta está literalmente escrita ahí.

Paso 2: los cuatro errores que verás el 80 % del tiempo

Paso 3: el print bien puesto (sí, sirve, y mucho)

Hay gente que te dirá que depurar con print es de aficionados. Ignórala: es la técnica más usada del mundo, incluso por quienes lo niegan. Lo que importa es ponerlo bien:

# ❌ inútil: no sabes cuál de los seis prints es este
print(gasto)

# ✅ útil: etiqueta, tipo y valor
print(f"[sumar] gasto={gasto!r} tipo_monto={type(gasto['monto'])}")

El !r muestra el valor «tal cual está guardado», con comillas incluidas. Es lo que te revela que '1,250.50' es texto y no número —justo la información que necesitabas.

Paso 4: el depurador de verdad (5 minutos de tu vida)

Cuando el print no basta, Python trae un depurador integrado desde siempre. Pon esta línea donde quieras que el programa se pare:

breakpoint()

Ejecuta normal y el programa se detendrá ahí, dándote una consola en la que puedes escribir el nombre de cualquier variable para ver su valor. Cuatro comandos y ya lo sabes usar:

n   → ejecuta la línea siguiente
s   → entra dentro de la función
c   → continúa hasta el próximo breakpoint
q   → salir

En VS Code es aún más fácil: haz clic a la izquierda del número de línea (aparece un punto rojo) y pulsa F5.

Paso 5: la bisección, el arma definitiva

Cuando no tienes ni idea de dónde está el fallo, no leas todo el código. Parte el problema por la mitad.

Comenta la mitad del programa. ¿Sigue fallando? El error está en la mitad que queda. ¿Ya no falla? Está en la que comentaste. Repite. Con diez pasos de bisección localizas un fallo en mil líneas.

Es el mismo principio de git bisect, que usarás dentro de un año para encontrar en qué commit se rompió algo.

🧠 La regla de los 20 minutos. Si llevas 20 minutos atascado en el mismo error sin ninguna hipótesis nueva, para. Levántate, camina cinco minutos, y vuelve. Si sigues atascado otros 20, entonces pregunta —a una IA, a un foro, a alguien—. Ni antes (no aprendes) ni mucho después (te desmoralizas). Ese cronómetro es, literalmente, el hábito que más separa a quien termina de quien abandona.

---

Git y GitHub: lo mínimo imprescindible

Git guarda el historial de tu código. GitHub lo aloja en internet. Empieza a usarlo en la semana 3, no cuando «ya sepas programar»: tu repositorio de GitHub va a ser tu currículum, y un historial de un año de commits pequeños vale más que cualquier certificado.

Estos ocho comandos cubren el 95 % de tu primer año:

git init                      # empezar a versionar esta carpeta
git status                    # ¿qué cambió?  (úsalo constantemente)
git add .                     # preparar todos los cambios
git commit -m "Añade reporte por categoría"   # guardar un punto
git log --oneline             # ver el historial
git push                      # subir a GitHub
git pull                      # bajar cambios de GitHub
git checkout -- archivo.py    # deshacer cambios de un archivo

Tres reglas que valen por un curso entero:

1. Commits pequeños y frecuentes. Uno por cambio con sentido, no uno por día. El mensaje se escribe en presente y dice qué hace, no qué tocaste: «Añade validación de montos negativos», no «cambios».
2. Nunca subas secretos. Contraseñas, claves de API y archivos .env no van a GitHub jamás. Una vez subido, considéralo filtrado aunque borres el commit.
3. Usa un .gitignore desde el primer commit. Evita subir el .venv, los __pycache__ y la basura del sistema operativo.

---

Cómo usar la IA sin dejar de aprender

Este es el capítulo que hace que esta guía de 2026 no se parezca a una de 2021. Léelo dos veces.

La IA es, sin exagerar, la mejor herramienta de aprendizaje que ha existido para programar: tienes un tutor infinitamente paciente que te explica cualquier error a las tres de la mañana. Y también es la forma más rápida de no aprender nunca. Las dos cosas son ciertas y dependen enteramente de cómo la uses.

Lo que dicen los datos (y por qué deberías tomártelos en serio)

• El 62 % de los profesionales del conocimiento reconoce que piensa críticamente menos cuando usa IA, según el estudio de Microsoft Research y Carnegie Mellon sobre 936 usos reales. El mismo trabajo encuentra el detalle decisivo: cuanta más confianza tienes en la IA, menos verificas; cuanta más confianza tienes en ti, más verificas. Cuando estás aprendiendo, tu confianza en ti es baja por definición. Estás justo en el perfil de máximo riesgo.
• Solo el 3,1 % de los desarrolladores confía mucho en la exactitud de la IA, frente al 45,7 % que desconfía, según la encuesta de Stack Overflow 2025. Y el dato que más te conviene retener: cuando no se fían de una respuesta de la IA, el 75,3 % acude a otra persona. El criterio humano sigue siendo el árbitro — y ese criterio es exactamente lo que estás construyendo tú ahora.
• El estudio de METR sobre productividad midió algo brutal: desarrolladores experimentados fueron un 19 % más lentos usando IA, y aun así creyeron haber sido un 20 % más rápidos. La sensación de estar aprendiendo rápido no es prueba de estar aprendiendo. (Nota honesta: METR ha marcado ese resultado como histórico y en 2026 encontró indicios de aceleración en experimentos posteriores. Lo que no ha cambiado es la brecha entre percepción y realidad, que es lo que aquí importa.)

Junta las tres cosas y tienes el retrato del forever junior: alguien que produce código que funciona, no sabe explicarlo, y se queda paralizado en cuanto el problema sale del terreno donde la IA acierta.

El protocolo de los dos sombreros

La solución no es prohibirse la IA —sería absurdo y te dejaría fuera del mercado—. La solución es no llevar nunca los dos sombreros a la vez.

graph TB
    A[Tarea nueva] --> B{¿Es un concepto<br/>que estoy aprendiendo?}
    B -->|Sí| C[SOMBRERO DE ALUMNO]
    B -->|No: es repetitivo<br/>o ya lo domino| D[SOMBRERO DE PILOTO]
    C --> E[Escríbelo tú primero.<br/>Aunque salga feo]
    E --> F[Que funcione]
    F --> G[Ahora sí: pide revisión<br/>y explicación a la IA]
    G --> H[Reescribe tú lo que aprendiste]
    D --> I[Delega, pero lee<br/>línea por línea]
    I --> J[Si no lo entiendes,<br/>no lo aceptas]
    H --> K[Aprendiste]
    J --> K

Sombrero de alumno (los primeros 6 meses, casi siempre): escribes tú primero. Siempre. Aunque tardes cuarenta minutos y te salga horrible. Solo después de que funcione le pides a la IA que lo revise y te explique qué haría distinto. El orden es innegociable, porque el aprendizaje ocurre en el esfuerzo de intentarlo, no en la lectura de la solución.

Sombrero de piloto (más adelante, y para lo aburrido): delegas y revisas. Pero revisas de verdad, línea por línea, con el criterio de que si no entiendes una línea, no entra en tu código.

Los cinco prompts que sí te enseñan

La diferencia entre usar la IA como tutor o como muleta está casi entera en cómo le pides las cosas.

Fíjate en el patrón: le pides pistas, comparaciones, casos límite y ejercicios; nunca la solución completa. El último —pedir ejercicios y traer tus intentos— convierte al modelo en el profesor particular que no te podías pagar.

El semáforo: qué delegar y qué no

El test de la explicación (hazlo cada viernes)

Abre el código que escribiste esta semana. Elige tres bloques al azar. Explícalos en voz alta, como si le hablaras a alguien que sabe programar pero no ha visto tu proyecto.

• Si puedes: ese código es tuyo, lo hayas escrito con IA o sin ella.
• Si no puedes: bórralo y vuelve a hacerlo. No es tuyo, y en una entrevista técnica se va a notar en treinta segundos.

Es incómodo y es la práctica más rentable de esta guía entera.

⚠️ El error que verás en todos lados. Mucha gente aprende a dirigir un agente de IA antes de saber leer código, y produce aplicaciones enteras que funcionan… hasta que dejan de hacerlo. Cuando eso pasa —y pasa— no hay a quién preguntarle, porque el agente ya no cabe el proyecto entero en su contexto y tú no entiendes ni el primer archivo. Sobre los riesgos concretos de ese código, escribí vibe coding seguro: entre el 40 % y el 60 % del código generado por modelos trae alguna vulnerabilidad del OWASP Top 10.

Qué herramientas usar (agosto de 2026)

Para aprender, tres son suficientes y las tres tienen plan gratuito:

• Un chat (Claude, ChatGPT o Gemini) para explicaciones, dudas y el rol de tutor. Es el que más vas a usar y el que mejor encaja con el protocolo de arriba.
• Autocompletado en el editor (GitHub Copilot, gratis para estudiantes y con cuota gratuita general). Apágalo los primeros tres meses. Completar tu línea antes de que la pienses es exactamente lo que impide que la aprendas.
• Un agente (Claude Code, Cursor, Codex) para proyectos. No lo toques hasta el mes 6. Antes de eso solo te va a construir cosas que no entiendes.

Si más adelante te interesa cuánto cuesta operar esto en serio, tengo los números en cuánto cuesta programar con agentes de IA.

---

La ruta de 12 meses, mes a mes

Doce meses a 10 horas semanales — unas 500 horas en total. Es el mínimo realista para llegar a nivel contratable, y es un plan sostenible con un trabajo y una familia. Con 20 horas semanales lo recorres en seis o siete meses; con 4 horas, en dos años. Lo que no funciona es hacer 30 horas una semana y ninguna las tres siguientes.

Cómo se reparten esas 10 horas

Este reparto importa más que el total:

• 6 h escribiendo código tú. Ejercicios y proyecto. Es lo único que produce aprendizaje de verdad.
• 2 h leyendo código ajeno. Repositorios pequeños en GitHub, la documentación oficial, tu propio código de hace un mes. Nadie hace esto y es donde se gana el salto de junior a algo más.
• 1 h de teoría. Un vídeo, un capítulo, un curso. Solo una hora. Más que eso es la trampa de la que hablo abajo.
• 1 h de repaso y notas. Reescribir con tus palabras lo que aprendiste esta semana. Suena a colegio y funciona por la misma razón por la que funcionaba en el colegio.

Las tres bifurcaciones del mes 6

Si dudas: backend con Python. Es la ruta con más puestos, la que menos depende de las modas y la que mejor te prepara para todo lo demás. Y si acabas en el frontend, el camino natural pasa por entender los frameworks de JavaScript y por dominar CSS de verdad.

---

Los 7 proyectos que sí importan (y los que no)

Un portafolio con tres clones de tutorial vale cero. Quien contrata ha visto el mismo clon de Netflix cuatrocientas veces y sabe exactamente de qué vídeo de YouTube salió.

Lo que sí distingue a un portafolio es que resuelva un problema que existía antes de que tú necesitaras un portafolio.

Los criterios (aplícalos antes de empezar nada)

1. ¿Alguien lo usaría, aunque sea una sola persona? Tu madre, tu jefe actual, tú mismo. Si no, es un ejercicio, no un proyecto.
2. ¿Tiene datos reales? Datos de verdad = casos raros = decisiones interesantes que contar en una entrevista.
3. ¿Puedes explicar por qué elegiste cada pieza? Si la respuesta a «¿por qué esta base de datos?» es «es la que salía en el tutorial», no cuenta.
4. ¿Está desplegado? Un enlace que se abre vale diez veces más que un repositorio.
5. ¿Tiene README? Qué hace, capturas, cómo ejecutarlo, qué aprendiste, qué harías distinto. Es lo primero y a veces lo único que se lee.

Los 7, en orden de dificultad

1. Automatizador de una tarea tuya real. Renombrar facturas, ordenar descargas por tipo, extraer datos de PDFs a una hoja de cálculo. Empieza aquí: es pequeño, es útil desde el primer día y te obliga a tocar archivos, errores y casos raros.
2. Recolector de datos con API pública. Consulta una API cada día, guarda el histórico en SQLite y grafica la evolución. Tocas APIs, base de datos, tareas programadas y visualización.
3. Herramienta de línea de comandos con argumentos. El analizador de gastos de esta guía, terminado de verdad: argparse, validación, mensajes de error útiles, publicado en PyPI si te animas.
4. API REST con autenticación. Usuarios, login, permisos, y documentación automática. Es el proyecto que más se parece a lo que harás en un trabajo.
5. Panel web sobre datos reales. Precios, clima, transporte público de tu ciudad, resultados deportivos. Backend + frontend + despliegue.
6. Integración entre dos servicios que usas. Que un formulario cree una fila en una hoja de cálculo y mande un WhatsApp. Es exactamente lo que las PyMEs pagan, y casi nadie junior lo tiene en el portafolio.
7. Contribución a un proyecto de código abierto. Un arreglo pequeño, una mejora de documentación, un test que faltaba. Demuestra que sabes leer código ajeno y trabajar con el proceso de otro — la señal más escasa en un perfil junior.

💡 El truco del proyecto ancla. En vez de siete proyectos separados, coge uno y hazlo crecer durante seis meses: primero script, luego con base de datos, luego con API, luego con interfaz, luego desplegado, luego con tests. El historial de commits cuenta la historia de tu aprendizaje mejor que cualquier carta de presentación, y evita el portafolio de cosas a medias.

---

Cómo no abandonar (la parte que nadie te cuenta)

De cada diez personas que empiezan a aprender a programar por su cuenta, terminan una o dos. La diferencia casi nunca es la inteligencia. Son estas cuatro cosas.

1. El valle de la desesperación

Existe y hay que verlo venir:

• Semanas 1-3 — euforia. Todo es nuevo, todo funciona, sientes que vuelas.
• Semanas 4-10 — el valle. Aparece la sensación de que no entiendes nada, de que todos los demás lo pillan más rápido y de que estás perdiendo el tiempo. Aquí abandona el 70 %.
• Semanas 11-20 — la salida. Empiezas a resolver cosas sin ayuda. El clic ocurre sin avisar.
• Mes 6 en adelante — competencia. Lo difícil ya no es el lenguaje, es decidir cómo estructurar.

El valle no es una señal de que no sirves. Es la fase en la que ya sabes lo suficiente como para darte cuenta de todo lo que no sabes. Es literalmente una consecuencia de haber aprendido.

2. La trampa del tutorial

Ver a alguien programar produce la misma sensación agradable que ver a alguien cocinar, y enseña lo mismo: nada. Si sigues un vídeo tecleando lo que aparece en pantalla, te sientes productivo y no estás aprendiendo, porque nunca tomas la decisión difícil (¿qué escribo ahora?).

Antídoto, y es duro pero funciona: por cada hora de tutorial, dos horas construyendo algo que el tutorial no cubría. Si sigues un curso de una API de tareas, hazte luego una de gastos, sin mirar. Ahí es donde aparece el aprendizaje.

3. La constancia le gana a la intensidad

Una hora al día durante seis días bate a seis horas el domingo, y no es motivación barata: la memoria consolida con el sueño y con la repetición espaciada. Seis contactos con el material producen mucha más retención que uno largo.

Prácticamente: bloquea la misma hora todos los días. Si un día no puedes, haz veinte minutos. La cadena importa más que la duración; lo que mata es el cero.

4. Programar solo es más difícil de lo que parece

No es cuestión de ánimo: atascarte sin que nadie te desatasque es la causa mecánica del abandono. Busca al menos uno de estos:

• Un Discord activo de tu lenguaje en español (los hay grandes y sanos).
• Un compañero de estudio con quien te reportes los viernes. Solo eso multiplica la tasa de finalización.
• Un meetup o comunidad local. Aunque no entiendas la mitad de las charlas el primer año.
• Escribir en público lo que aprendes: un hilo, un post, un repo con notas. Explicar consolida, y de paso construye tu reputación antes de tener experiencia.

---

Del portafolio al primer trabajo

Hablemos de números, y con honestidad.

Cuánto se cobra realmente en México

Esa última fila merece un comentario, porque la vas a leer mucho: es marketing. La cifra que verás en los blogs de las academias corresponde, como mucho, a un perfil junior en una empresa de producto o con cliente extranjero, y no al puesto al que accedes con doce meses de estudio. Contrastar tu expectativa con Indeed y Computrabajo, que salen de ofertas reales, te ahorrará una decepción cara.

Dónde sí está el dinero rápido: el trabajo remoto para el extranjero cambia la escala por completo, y no exige título. Exige inglés funcional, un portafolio que se pueda abrir y saber trabajar en asíncrono. Ese es el objetivo del año dos, no del mes doce.

Qué busca quien contrata en 2026

El mercado junior cambió; el perfil que se pide, también:

1. Que entregues algo completo, no una función. Base de datos, lógica, interfaz y desplegado.
2. Que sepas usar IA y también revisarla. Decir «uso Claude Code a diario» ya no diferencia a nadie. Diferencia poder contar un caso en el que detectaste que la IA se equivocó y por qué.
3. Que hables con humanos. Traducir un problema de negocio a un plan técnico es la habilidad más escasa y menos automatizable.
4. Que tengas huella pública. GitHub con actividad real, y —si te atreves— algo escrito.

Las cuatro puertas de entrada, de más a menos accesible

💡 La estrategia que más veo funcionar. Ofrécete a automatizar algo en el trabajo que ya tienes. Reportes, conciliaciones, cargas de datos, correos. Con eso consigues las tres cosas imposibles a la vez: un caso real y verificable para el portafolio, experiencia profesional que puedes poner en el CV, y a menudo un cambio de puesto sin cambiar de empresa. Si tu trabajo actual no es técnico, esa es tu mayor ventaja competitiva, no tu desventaja.

---

Recursos gratis que valen la pena en 2026

Todo lo que necesitas para llegar a nivel contratable es gratis. De verdad. Estos son los que siguen siendo buenos, con su letra pequeña:

Cómo combinarlos sin perder el tiempo: uno principal (freeCodeCamp o The Odin Project), Exercism en paralelo para práctica corta, CS50 a partir del mes 4 para los fundamentos, y la documentación oficial como consulta. No hagas dos rutas principales a la vez. Es la forma más común de no terminar ninguna.

¿Y los bootcamps de pago?

Pueden valer la pena, con una condición: que compres lo que un bootcamp sí da y no puedes conseguir gratis, que es estructura, ritmo y gente. Lo que no compra es aprendizaje: eso lo pones tú igual.

Antes de pagar, pide tres cosas por escrito: el porcentaje de inserción verificable (no «el 90 % de los que buscaron activamente»), el perfil real de los profesores, y contacto con dos egresados de hace un año. Si esquivan cualquiera de las tres, ya tienes tu respuesta.

---

Los errores que matan el 90 % de los intentos

Los he visto todos, y casi todos son evitables:

1. Elegir lenguaje durante seis semanas. Ninguna elección es irreversible. Empieza hoy con Python.
2. Aprender viendo, no escribiendo. Si tu semana fueron 8 horas de vídeo y 1 de teclado, no estás aprendiendo.
3. Saltar a un framework sin fundamentos. Django o React sobre una base floja construyen un castillo de naipes que se cae en el primer error raro.
4. Pegar código de la IA que no entiendes. Funciona hoy y te bloquea para siempre.
5. Estudiar sin construir nada. Sin proyecto no hay portafolio, y sin portafolio no hay entrevista.
6. Compararte con gente que lleva diez años. Compárate con tu yo de hace un mes. Es la única comparación con información útil.
7. Perseguir cada tecnología nueva. Terminar una cosa vale más que empezar cinco.
8. No usar Git desde el principio. Pierdes un año de evidencia de tu propio progreso.
9. Esperar a «estar listo» para postular. Nunca vas a sentirte listo. Postula al mes 10 con lo que tengas: cada entrevista es información gratis sobre lo que te falta.
10. Abandonar en la semana 6. Es el valle. Le pasa a todo el mundo. Aguanta cuatro semanas más.

---

Preguntas frecuentes

¿Cuánto tardo? Unos 12 meses a 10 horas semanales para llegar a nivel contratable; los primeros resultados útiles, hacia el mes 3.

¿Qué lenguaje? Python, salvo que tu objetivo sea específicamente construir interfaces web: entonces JavaScript.

¿Y la IA? Úsala como tutor, nunca como generador: escribe tú primero y, si no puedes explicar una línea en voz alta, bórrala.

---

Por dónde empezar hoy, en 30 minutos

Si has llegado hasta aquí, el peor resultado posible es cerrar la pestaña y no hacer nada. Así que reduzco todo a lo que puedes hacer ahora mismo:

1. Instala Python 3.14 y VS Code (15 minutos).
2. Crea hola.py y ejecútalo (2 minutos).
3. Escribe un programa que te pregunte tres gastos y te diga el total y el promedio. Sin usar IA. Tardarás más de lo que crees, y ese esfuerzo es exactamente el aprendizaje (20 minutos).
4. Crea tu cuenta de GitHub y sube ese archivo (10 minutos).

Eso es el día 1 de 365. El resto es repetirlo.

Y una última cosa, que es la que de verdad importa: lo raro no es tardar en entender algo. Lo raro es seguir ahí en la semana 8. Casi todo el mundo que hoy vive de esto pasó por el mismo valle, y la única diferencia entre quien lo cruzó y quien no fue no parar.

¿Estás empezando y te has atascado en algo concreto? Cuéntamelo —qué error te salió y qué has probado— y si andas montando el entorno, dime en qué paso te quedaste. Y si lo que necesitas es que alguien construya o automatice algo por ti mientras aprendes, eso también lo hago.