Los feeds de redes sociales muestran al developer Python trabajando desde terrazas con vistas al mar con una taza de café, laptop reluciente y cuatro horas de trabajo al día. La realidad es más interesante y más matizada que eso.
Aquí está el día a día real de un programador Python que trabaja de forma remota y viaja.
Una semana típica: cómo se ve en la práctica
Lunes: contexto y arranque
Los lunes no empiezan con código. Empiezan con contexto.
Mañana (8:00-10:00):
- Revisión de mensajes acumulados del fin de semana (Slack, email, GitHub notifications)
- Si hay empleo remoto: standup diario de 15 minutos con el equipo
- Si es freelance: llamada de kick-off semanal con el cliente principal (30 min)
Mañana profunda (10:00-13:00): El bloque de trabajo técnico de mayor concentración. VS Code abierto, teléfono en modo avión, notificaciones silenciadas. Para un proyecto de API, esto puede ser:
- Revisar el estado del código desde el viernes
- Continuar implementación de los endpoints pendientes
- Escribir tests para lo que se completó
Tarde (14:00-17:00):
- Segundo bloque de desarrollo (generalmente menos difícil que el de la mañana)
- Documentación y comentarios en código
- Commits y push con mensajes descriptivos
Martes-Miércoles: ejecución profunda
Los días centrales de la semana son los de mayor productividad. El patrón:
- Bloque de 3-4 horas de desarrollo puro en la mañana
- Revisión de PRs o código del equipo/subcontratistas (si aplica)
- Comunicación con cliente sobre avance (por Loom o Slack, no necesariamente llamada)
- Segundo bloque de desarrollo
Un miércoles típico en proyecto de automatización:
- 09:00: Revisar que el cron job de la noche corrió correctamente
- 09:30: Debug de un caso edge que no manejaba el script
- 11:00: Agregar logging apropiado para monitoreo en producción
- 13:00: Almuerzo, paseo, descanso real (no “trabajo con YouTube de fondo”)
- 14:30: Implementar notificaciones de error por email
- 16:30: Testing end-to-end del flujo completo
- 17:30: Commit, push, actualización de estado en Notion
Jueves: revisión y cliente
El día de mayor contacto con el cliente o equipo.
- Preparación de demo o actualización de avance
- Llamada de revisión (30-60 min): mostrar lo construido, recibir feedback
- Incorporar feedback prioritario
- Planificar entregables de la semana siguiente
Viernes: cierre y mantenimiento
- Terminar los pendientes de la semana
- Code review de PRs del equipo
- Revisar métricas de proyectos en producción (errores, performance)
- Actualizar documentación
- Planning informal de la semana siguiente
- 1-2 horas de aprendizaje: artículo técnico, explorar nueva librería, avanzar en curso
Las herramientas que abres cada día
| Herramienta | Función | Frecuencia |
|---|---|---|
| VS Code | Desarrollo Python | Diario |
| Terminal (zsh/bash) | Git, scripts, servers locales | Diario |
| GitHub | PRs, code review, historial | Diario |
| Slack / Discord | Comunicación de equipo/cliente | Diario |
| Notion | Tracking de tareas y documentación | Diario |
| Postman / httpie | Testing de APIs | 3-4 días/semana |
| DBeaver | Consultas a base de datos | 2-4 días/semana |
| Google Meet / Zoom | Llamadas | 2-3 veces/semana |
| Loom | Presentaciones asincrónicas | 1-2 veces/semana |
Los tipos de trabajo Python en el día a día
Si haces backend/APIs
Los bloques de trabajo se dividen entre:
- Implementación de features: escribir código nuevo según especificaciones
- Testing: escribir tests unitarios e integración (muchos teams exigen TDD)
- Code review: revisar código de compañeros o subcontratistas
- Debug: investigar y resolver bugs reportados
- Documentación: actualizar Swagger/OpenAPI, README, wikis internas
Si haces automatización
El trabajo es más irregular pero hay patrones:
- Exploración inicial: entender el proceso que se va a automatizar, fuentes de datos involucradas
- Desarrollo del script: implementación iterativa, con pruebas frecuentes contra datos reales
- Manejo de casos edge: los datos reales siempre tienen excepciones que el caso “normal” no cubre
- Deploy y monitoreo: subir a producción, verificar que corre en el ambiente real
- Mantenimiento: cuando el sitio o API que scrapeabas cambia su estructura
Si haces datos/ML
Los proyectos tienen fases largas en el Jupyter Notebook:
- Exploración de datos (puede tomar días en datasets complejos)
- Limpieza (la mayor parte del tiempo en proyectos reales)
- Feature engineering
- Entrenamiento y evaluación de modelos
- Comunicación de resultados (la más subestimada)
Los retos reales de programar Python siendo nómada
El hardware que realmente necesitas
Python no requiere hardware potente para la mayoría del trabajo:
- Laptop con 8-16 GB RAM y SSD
- Para ML con datasets grandes: Google Colab en la nube elimina la necesidad de GPU local
- Una laptop de $700-900 USD es suficiente para el 95% del trabajo
Lo que sí importa más que el hardware: la calidad del teclado y el monitor secundario (opcional pero productivo para debugging).
Conectividad real en diferentes ciudades
| Situación | Impacto en trabajo Python |
|---|---|
| Café con wifi lento (2-5 Mbps) | Funciona para desarrollo local. No para descargar datasets grandes o usar Colab |
| Coworking estándar (50+ Mbps) | Sin restricciones para 99% del trabajo |
| AirBnB sin verificar conexión | Riesgo real. Verificar siempre antes de reservar para estadías largas |
| VPN bloqueada (China, etc.) | Problema real si el cliente usa servicios bloqueados |
El 90% del desarrollo Python corre localmente. La nube (GitHub, deployment, Colab) requiere buena conexión pero no en tiempo real constante.
Concentración en entornos cambiantes
El debugging de un error sutil o el diseño de arquitectura requieren concentración profunda que los cafés no siempre permiten. El patrón que aprenden los nómadas con experiencia:
- Coworking para trabajo técnico profundo: silencio, ergonomía, conexión garantizada
- Café para trabajo liviano: comunicación, code review, documentación, planning
- Hostal o Airbnb solo para reuniones de video cuando el coworking no está disponible
El costo del coworking diario ($5-20 según ciudad) es una inversión directa en productividad, no un gasto.
¿Trabajas con Python de forma remota y quieres compartir tu rutina real? En el foro de Nomadaz hay developers intercambiando sus experiencias reales del trabajo técnico nómada. Únete a la conversación.