Docker es una de esas herramientas que todos mencionan pero pocos explican bien desde cero. La metáfora del contenedor de carga (la de los barcos) es, de hecho, la mejor forma de entenderlo.

1. El problema que resuelve

La frase clásica de todo programador: «en mi computadora funciona». Una aplicación puede andar perfecto en tu máquina y fallar en la del compañero o en el servidor, porque cambian versiones de software, configuraciones o dependencias instaladas.

2. La solución: empaquetar todo junto

Docker mete tu aplicación, junto con TODO lo que necesita para funcionar (versión específica de un lenguaje, librerías, configuraciones) dentro de un «contenedor»: un paquete autocontenido que corre igual en cualquier computadora que tenga Docker instalado. Como un contenedor de carga real: no importa qué barco, grua o camión lo transporte, lo de adentro llega intacto.

3. Contenedor no es lo mismo que máquina virtual

Una máquina virtual simula una computadora completa (con su propio sistema operativo entero), lo que la hace pesada y lenta de iniciar. Un contenedor comparte el sistema operativo de la máquina anfitriona y solo empaqueta lo que la aplicación necesita, lo que lo hace muchísimo más liviano y rápido de levantar (segundos, en vez de minutos).

4. Por qué le importa incluso a alguien que no programa

Si trabajás con un equipo de desarrollo, Docker es la razón por la que pueden decir «levantá el proyecto con un solo comando» en vez de pasar horas instalando cosas manualmente. También es la base de cómo funcionan hoy la mayoría de los servicios en la nube a gran escala.

5. ¿Necesitás aprenderlo?

Si trabajás en desarrollo web o backend, sí, tarde o temprano te lo vas a cruzar. Los comandos básicos (levantar, bajar y ver contenedores corriendo) se aprenden en una tarde; dominarlo a fondo (redes entre contenedores, orquestación con Kubernetes) lleva más tiempo, pero no hace falta para empezar a aprovecharlo.

«Sin experiencia laboral» no significa «sin nada para mostrar». Un portfolio bien armado puede pesar más que un año de experiencia mal comunicado.

1. Elegí 3 proyectos, no 15

Un portfolio con 15 proyectos a medio terminar comunica dispersión. Tres proyectos completos, funcionando, con código prolijo, comunican mucho más criterio que una lista larga incompleta.

2. Resolvé un problema real, no un tutorial copiado

Los reclutadores ven cientos de «clones de Netflix» y «todo list apps» hechos siguiendo un tutorial paso a paso. Destacá mucho más un proyecto que resuelva un problema específico tuyo o de alguien cercano, aunque sea chico: una calculadora de gastos compartidos, un scraper de precios, una herramienta para organizar algo que vos mismo necesitabas.

3. Documentá el proceso, no solo el resultado

Para cada proyecto, agregá un breve texto explicando qué problema resolvés, qué decisiones técnicas tomaste y por qué, y qué harías distinto si lo rehicieras hoy. Esto demuestra capacidad de reflexión técnica, que es justamente lo que buscan en un junior (nadie espera que sepas todo, pero sí que pienses).

4. Contribuí a un proyecto open source, aunque sea chico

Una contribución real a un repositorio de otra persona (aunque sea arreglar un typo en la documentación o un bug chico) demuestra que sabés trabajar con código ajeno y seguir el flujo de Git colaborativo, algo que muy pocos juniors pueden mostrar.

5. El sitio del portfolio en sí importa

No hace falta que sea complejo, pero sí que esté prolijo, cargue rápido y funcione bien en celular. Es, literalmente, tu primer proyecto público: si tiene errores o se ve descuidado, manda una señal contradictoria sobre tu atención al detalle.

Conclusión: la calidad y el criterio detrás de tres proyectos bien pensados pesan más que la cantidad. Priorizará profundidad sobre volumen.

Es una de las primeras decisiones técnicas que hay que tomar al armar un proyecto, y elegir mal puede costarte reescribir todo más adelante. Acá la diferencia explicada sin jerga.

1. SQL (bases de datos relacionales)

Organiza los datos en tablas con filas y columnas, como una planilla de Excel bien estructurada, donde cada tabla se relaciona con otras mediante claves. Ejemplos: MySQL, PostgreSQL, SQL Server. Son ideales cuando tus datos tienen una estructura clara y estable, y necesitás que las relaciones entre ellos sean consistentes siempre (por ejemplo, un sistema de facturación, donde cada factura debe estar sí o sí asociada a un cliente válido).

2. NoSQL (bases de datos no relacionales)

Guarda los datos de formas más flexibles: documentos tipo JSON, pares clave-valor, grafos, según el tipo. Ejemplos: MongoDB, Redis, Firebase. Son ideales cuando tu estructura de datos cambia seguido, necesitás velocidad extrema en lecturas/escrituras masivas, o estás manejando datos muy variados que no encajan bien en tablas rígidas.

3. La pregunta que realmente define la elección

¿Tus datos tienen relaciones estrictas que necesitan mantenerse consistentes sí o sí (como órdenes de compra, pagos, inventario)? Elegí SQL. ¿Necesitás velocidad y flexibilidad por sobre estructura rígida (como registros de actividad, contenido de redes sociales, caché de sesiones)? Elegí NoSQL.

4. El error más común de principiantes

Elegir NoSQL solo porque «suena más moderno» sin necesitarlo realmente. La mayoría de las aplicaciones de negocio (tiendas online, sistemas de gestión, CRMs) funcionan perfectamente bien, y a veces mejor, con una base de datos SQL tradicional.

En la práctica: muchos proyectos grandes usan ambas a la vez, cada una para lo que mejor resuelve. No es una decisión de «para siempre»: elegí según el problema específico que tenés hoy.

Es la pregunta que más repiten quienes recién empiezan: ¿por dónde arranco? La respuesta correcta depende menos de «cuál es el mejor lenguaje» y más de qué querés construir.

1. Si tu objetivo es conseguir trabajo rápido

Python y JavaScript siguen siendo la puerta de entrada más pedida en ofertas laborales de nivel junior. Python por su sintaxis simple y su uso en backend, datos y automatización; JavaScript porque es el único lenguaje que corre nativo en el navegador, lo que lo hace imprescindible para cualquier cosa de frontend.

2. Si te interesa el desarrollo de apps móviles

Empezá directamente con Kotlin (Android) o Swift (iOS), o si querés cubrir ambas plataformas con un solo código, Dart con Flutter. No hace falta pasar primero por otro lenguaje «más fácil»: estos ya están diseñados para ser accesibles.

3. Si te atrae la ciencia de datos o la IA

Python, sin vueltas. Es el estándar de facto en el ecosistema de datos e inteligencia artificial, con la mayor cantidad de librerías y comunidad para resolver problemas ya armados.

4. El error más común al elegir

Cambiar de lenguaje cada dos semanas persiguiendo «el que está de moda». La lógica de programar (variables, condicionales, bucles, funciones) es la misma en casi todos los lenguajes populares; una vez que la entendés en uno, aprender el siguiente lenguaje te lleva semanas, no meses. Mejor invertir seis meses serios en uno solo que dispersarte.

Conclusión: elegí según lo que querés construir, no según rankings genéricos de internet. El mejor lenguaje para empezar es el que te mantiene motivado para seguir practicando todos los días.