El problema de la inseguridad
He hablado con docenas de estudiantes que dicen: “No tengo nada que valga la pena escribir.”
Han construido:
- Una aplicación de lista de tareas
- Un panel meteorológico
- Un juego simple
- Una visualización de datos
- Un bot de Discord
Pero no escriben sobre ellos porque “todos han hecho eso” o “es muy básico.”
La verdad es: La complejidad del proyecto no importa. Lo que importa es cómo hablas de él.
Un proyecto “simple” bien documentado supera a un proyecto “complejo” sin documentar cada vez.
¿Por qué escribir sobre proyectos pequeños?
1. Demuestra habilidades de comunicación
Escribir claramente sobre trabajo técnico es una habilidad fundamental. La mayoría de los desarrolladores pueden programar. Menos pueden explicar su código.
2. Muestra tu proceso
Los reclutadores quieren ver cómo piensas, no solo qué construiste. Un proyecto simple con razonamiento claro es más impresionante que un proyecto complejo sin explicación.
3. Construye tu portafolio
Necesitas contenido. Tres proyectos pequeños bien documentados superan a cero proyectos grandes documentados.
4. Te ayuda a aprender
Escribir te obliga a entender qué hiciste y por qué. Es una herramienta de aprendizaje, no solo una vitrina.
5. SEO y descubrimiento
Cuando los reclutadores te buscan en Google, encuentran tu trabajo. Cuando otros estudiantes buscan soluciones, encuentran tus publicaciones. Ambos son valiosos.
El framework: Antes/Después
La forma más simple de enmarcar cualquier proyecto es: “Antes de esto, X era un problema. Después de esto, X está resuelto.”
Ejemplo: App de lista de tareas
Enfoque débil:
“Construí una app de lista de tareas con React.”
Enfoque fuerte:
“Estaba usando notas en papel y perdiendo el seguimiento de tareas. Construí una app web para organizar mis tareas por prioridad y fecha de vencimiento. Ahora tengo un solo lugar para gestionar todo, y aprendí React en el proceso.”
¿Ves la diferencia? La segunda versión:
- Explica la motivación (problema real)
- Describe la solución (funcionalidades específicas)
- Muestra el resultado (problema resuelto + habilidad aprendida)
Plantilla de documentación de proyectos
Aquí tienes una estructura que funciona para cualquier proyecto, grande o pequeño:
1. Descripción general (2-3 oraciones)
¿Qué es? ¿Qué hace? ¿Por qué lo construiste?
| |
2. El problema (1-2 párrafos)
¿Qué problema estabas resolviendo? Sé específico. Los problemas personales son problemas válidos.
| |
Por qué funciona:
- Detalles específicos (notas en papel, archivos de texto)
- Consecuencias reales (fechas límite perdidas)
- Motivación clara (aprender React + resolver problema)
3. Stack tecnológico
Lista lo que usaste y brevemente por qué.
| |
No solo listes tecnologías. Agrega una oración explicando tu elección.
4. Características principales
¿Qué puede hacer? Usa viñetas para claridad.
| |
5. Lo que aprendí
Esta es la sección más importante. ¿Qué habilidades desarrollaste?
| |
Por qué funciona:
- Habilidades específicas, no afirmaciones vagas
- Muestra profundidad de aprendizaje
- Demuestra que entiendes lo que hiciste
6. Desafíos y soluciones
¿Qué salió mal? ¿Cómo lo arreglaste? Esto muestra resolución de problemas.
| |
Lo que aprendí: Mantén el estado mínimo y deriva valores cuando sea posible. Esto reduce errores y hace el código más fácil de razonar.
Desafío 2: Diseño móvil
Problema: El diseño de escritorio se rompía en móvil. Los botones eran muy pequeños y la lista de tareas era difícil de leer.
Solución: Adopté un enfoque mobile-first, diseñando primero para pantallas pequeñas y luego agregando complejidad para pantallas más grandes.
| |
Lo que aprendí: El diseño mobile-first es más fácil que intentar hacer un diseño de escritorio responsivo. Empieza pequeño y agrega complejidad.
Por qué funciona:
- Números concretos (200+ tareas, 3 meses)
- Uso real (uso diario)
- Validación externa (otros lo usan)
- Impacto medible (30 minutos ahorrados)
8. Mejoras futuras
¿Qué agregarías después? Muestra que estás pensando a futuro.
| |
9. Conclusiones
Termina con 3-5 lecciones concretas.
| |
Ejemplo real: Reenmarcando un proyecto “simple”
Tomemos un proyecto básico y mostremos cómo presentarlo bien.
Proyecto: Panel meteorológico
Versión débil:
“Hice una app del clima usando una API del clima. Muestra la temperatura y las condiciones.”
Versión fuerte:
Panel meteorológico
Un panel meteorológico limpio y rápido que muestra las condiciones actuales y un pronóstico de 5 días para cualquier ciudad.
Demo en vivo: weather.yoursite.com GitHub: github.com/you/weather-dashboard
El problema
Estaba cansado de abrir weather.com y lidiar con anuncios, carga lenta e interfaces desordenadas. Quería una forma rápida y limpia de verificar el clima, especialmente al planificar mi viaje en bicicleta al campus.
Qué lo hace diferente
- Rápido: Carga en menos de 1 segundo
- Limpio: Sin anuncios, sin desorden, solo datos meteorológicos
- Útil: Muestra temperatura “se siente como” y velocidad del viento (importante para andar en bici)
- Persistente: Recuerda tu última ciudad buscada
Stack tecnológico
- Frontend: JavaScript vanilla (quería practicar fundamentos sin frameworks)
- API: OpenWeatherMap API
- Estilos: CSS Grid y propiedades personalizadas
- Despliegue: GitHub Pages
Lo que aprendí
Integración con API:
- Hacer peticiones HTTP con
fetch() - Manejar errores de API y límites de uso
- Parsear respuestas JSON
- Asegurar claves API (variables de entorno)
JavaScript asíncrono:
- Promesas y async/await
- Manejo de errores con try/catch
- Estados de carga y retroalimentación al usuario
UI/UX:
- Pantallas skeleton mientras carga
- Mensajes de error que ayudan a los usuarios
- Diseño responsivo para móvil
- Accesibilidad (navegación por teclado, etiquetas ARIA)
Desafíos
Desafío: Seguridad de la clave API
Inicialmente codifiqué mi clave API en el archivo JavaScript. Un compañero señaló que esto era visible en las herramientas de desarrollo del navegador.
Solución: Moví la clave API a un proxy backend (una función simple de Netlify) que hace la llamada real a la API. El frontend llama a mi proxy, que agrega la clave API del lado del servidor.
Lo que aprendí: Nunca expongas claves API en código frontend. Siempre usa un proxy backend o variables de entorno.
Resultados
- ⚡ Carga 5x más rápido que weather.com
- 🚴 Lo reviso cada mañana antes de ir en bici a clase
- 👥 10 amigos lo agregaron a favoritos y lo usan regularmente
- 📱 Funciona perfectamente en móvil
- ⭐ 15 estrellas en GitHub al compartirlo en Reddit
Planes futuros
- Agregar alertas meteorológicas
- Soporte para múltiples ciudades guardadas
- Datos meteorológicos históricos
- Sugerencias de actividades basadas en el clima ("¡Buen día para andar en bici!")
Conclusiones
- Resuelve tus propios problemas: Lo uso diariamente porque resuelve un problema real que tenía.
- Simple puede ser mejor: Una herramienta enfocada que hace una cosa bien supera a una herramienta compleja que hace todo mal.
- La seguridad importa: Aprender sobre seguridad de claves API temprano me salvó de un error costoso.
- Comparte tu trabajo: Publicar en Reddit llevó a gran retroalimentación y usuarios.
¿Ves cuánto más convincente es eso? Mismo proyecto, mejor presentación.
Errores comunes a evitar
1. Disculparte por la simplicidad
No digas:
- “Este es solo un proyecto simple…”
- “Sé que esto no es muy impresionante…”
- “Todos han hecho esto antes…”
En su lugar:
- Enfócate en lo que aprendiste
- Enfatiza el problema que resolviste
- Muestra tu enfoque o ideas únicos
2. Solo mostrar código
Código sin contexto es difícil de evaluar. Siempre explica:
- Por qué lo escribiste de esta manera
- Qué problema resuelve
- Qué alternativas consideraste
3. Saltarte el “por qué”
No solo digas qué construiste. Explica:
- Por qué lo construiste
- Por qué elegiste estas tecnologías
- Por qué tomaste decisiones específicas
4. Sin elementos visuales
Agrega capturas de pantalla, diagramas o GIFs. La prueba visual hace tu proyecto más tangible.
5. Ignorar los fracasos
Los fracasos son oportunidades de aprendizaje. Comparte lo que no funcionó y lo que aprendiste de ello.
Enlazando a GitHub
Tu publicación del proyecto debe enlazar a tu repositorio en GitHub. Asegúrate de que tu repositorio tenga:
Secciones esenciales del README
| |
Uso
[Cómo usarlo]
Tecnologías
- Tecnología 1
- Tecnología 2
Lo que aprendí
[Breve resumen]
Licencia
MIT
✅ Bien:
- “Add task filtering by priority”
- “Fix mobile layout overflow issue”
- “Implement LocalStorage persistence”
❌ Mal:
- “Update”
- “Fix stuff”
- “Changes”