Envelope Facebook Instagram Linkedin

S01E01 — Hello, n00b: qué significa aprender tecnología de verdad

Intro con gancho

Todos hemos sido n00b. La diferencia entre “soy n00b” y “me quedé n00b” no es talento, ni una laptop con luces RGB. Es método.

Aprender tecnología “de verdad” no se trata de ver 40 horas de videos y sentir que ya “sabes”. Se trata de poder resolver un problema real, con herramientas reales, bajo presión real, y dejarlo funcionando para que alguien más lo use (o te pague por eso).

Este episodio es el arranque del arco Origen: cómo se ve el aprendizaje cuando dejas de coleccionar tutoriales y empiezas a construir criterio.

Qué vas a aprender

Contexto práctico

En IT hay dos tipos de progreso:

  1. Progreso percibido: “ya me eché el curso de X”.
  2. Progreso comprobable: “aquí está el repo, el deploy, el bug que arreglé y el postmortem”.

La industria premia el #2.

Definición operativa: aprender tecnología de verdad

Aprendiste algo cuando puedes:

Si no puedes hacer eso, no es fracaso: es señal de que estás en la fase normal de “conozco palabras, no tengo callo”.

El enemigo real del n00b

No es “no saber”. Es:

Ese dolor es el entrenamiento.

Paso a paso o guía principal

La guía es simple: elige un problema pequeño + construye una solución completa + compártela + repite.

Paso 0: Escoge tu primer “problema real” (pequeño, pero de verdad)

Criterios:

Ideas (con sabor a mundo real):

Paso 1: Define “Done” como adulto

Si tu “done” es “ya medio jala”, nunca terminas.

Define “Done” con 5 bullets:

Ejemplo de “Done” para una mini API de tareas:

Paso 2: Elige stack inicial (sin drama)

No estás eligiendo “el stack de tu vida”. Estás eligiendo el stack para aprender el proceso.

Recomendación práctica para el primer sprint (por simplicidad y empleabilidad):

Elige una y quédate 14 días. El switching mata el progreso.

Paso 3: Arma tu entorno (lo mínimo viable)

Checklist:

Comandos ejemplo (Node + Express):

mkdir hello-noob-api && cd hello-noob-api
npm init -y
npm i express
npm i -D nodemon

git init

Un package.json con script de dev:

{
  "scripts": {
    "dev": "nodemon index.js"
  }
}

Paso 4: Construye vertical, no horizontal

Vertical = una rebanada completa que funciona, aunque sea fea.
Horizontal = 2 semanas “preparando la arquitectura” sin nada usable.

Ejemplo vertical (API mínima):

// index.js
const express = require('express');
const app = express();
app.use(express.json());

const tasks = [];

app.get('/health', (_, res) => res.json({ ok: true }));

app.post('/tasks', (req, res) => {
  const { title } = req.body;
  if (!title || typeof title !== 'string') {
    return res.status(400).json({ error: 'title requerido (string)' });
  }
  const task = { id: tasks.length + 1, title, done: false };
  tasks.push(task);
  res.status(201).json(task);
});

app.get('/tasks', (_, res) => res.json(tasks));

app.listen(3000, () => console.log('API en http://localhost:3000'));

Prueba rápida con curl:

curl -s http://localhost:3000/health
curl -s -X POST http://localhost:3000/tasks \
  -H 'Content-Type: application/json' \
  -d '{"title":"aprender de verdad"}'
curl -s http://localhost:3000/tasks

Luego, mejora en capas (persistencia, validación, tests, deploy). Pero primero: que viva.

Paso 5: Aprende a depurar (el superpoder que nadie presume)

Cuando algo falle (va a fallar), sigue este protocolo:

  1. Reproduce el error consistentemente.
  2. Reduce el caso (¿con qué input mínimo falla?).
  3. Observa (logs, stack trace, request/response).
  4. Hipótesis (una a la vez).
  5. Cambio pequeño y vuelve a probar.

Regla: si haces 5 cambios a la vez, no aprendiste nada.

Paso 6: Documenta como si tu “yo del futuro” te odiara

Tu README mínimo:

Plantilla rápida:

# Hello, n00b API

## Requisitos
- Node 20+

## Correr
npm i
npm run dev

## Endpoints
- GET /health
- POST /tasks {"title":"..."}
- GET /tasks

Paso 7: Cierra el ciclo: publícalo y pide feedback

Aprender en privado es cómodo. Aprender en público acelera.

Mínimo:

Screenshots sugeridos

(Para que el post se sienta “hands-on” en WordPress)

  1. Terminal corriendo npm run dev / uvicorn con el servidor levantado.
  2. Postman/Insomnia con el request POST /tasks y la respuesta 201.
  3. Resultado de GET /tasks mostrando lista.
  4. Vista del repo en GitHub con el README visible.
  5. Un ejemplo de error 400 por title faltante (para enseñar validación).

Errores comunes + solución

1) “Ya vi el curso, pero no puedo hacer nada solo”

Causa: consumo pasivo.
Solución: por cada 30 min de video, 60–90 min construyendo. Pausa y replica sin copiar/pegar.

2) Parálisis por análisis del stack

Causa: miedo a “equivocarte”.
Solución: elige un stack por 14 días. Lo importante es dominar el ciclo construir-depurar-documentar.

3) Copiar código sin entender

Causa: urgencia por “que funcione”.
Solución: regla del 3: si copias, debes (1) explicarlo, (2) cambiarlo, (3) romperlo a propósito y arreglarlo.

4) No sabes si lo estás haciendo bien

Causa: no hay criterios de terminado.
Solución: define “Done” antes de empezar. Si no, siempre te falta “una mejora más”.

5) Te atoras en errores de entorno

Causa: instalaciones, PATH, versiones.
Solución: registra versiones (node -v, python --version), usa un README con pasos exactos y considera contenedor después (no al día 1).

Checklist final

FAQ

1) ¿Cuánto tiempo al día necesito para avanzar?

Con 45–90 min diarios bien enfocados puedes avanzar mucho si construyes. Lo crítico es la constancia, no la maratón.

2) ¿Cuál lenguaje es mejor para empezar: Python o JavaScript?

El que te permita terminar proyectos rápido. Si apuntas a web, JavaScript/Node se siente directo. Si te interesa data/automation, Python es oro. Elige uno y deja el otro para el siguiente sprint.

3) ¿Cómo sé si ya “aprendí” X tema?

Si puedes implementarlo sin plantilla, explicarlo con tus palabras y depurarlo cuando falla. Si solo lo reconoces en un video, aún estás en fase de exposición.

4) ¿Cuándo debo aprender Git en serio?

Desde el día 1, pero en modo simple: init, add, commit, log, status. Branching avanzado después. El objetivo es tener historial y poder volver atrás.

5) ¿Está bien usar ChatGPT/copilots para aprender?

Sí, si lo usas como compañero de debugging, no como piloto automático. Pide explicaciones, alternativas y que te haga preguntas. Si no puedes defender el cambio, no lo metas.

Siguiente episodio: teaser

En el S01E02 vamos a aterrizar el “stack mínimo” y armar tu primer repo como se debe: estructura, commits, y un flujo de trabajo que no dé pena.

Trae tu proyecto mini: lo vamos a endurecer para que aguante la vida real.

Etiquetado , , , , , , , , , ,
Envelope Phone Facebook Instagram Linkedin