101 DEV: Los conceptos que todo dev debe conocer

En esta completa serie de entrevistas, presentada en colaboración con nuestros amigos del podcast GitBar, profundizamos en los conceptos que todo dev debe conocer para mantenerse actualizados en la industria tecnológica actual.

Desarrolladores destacados han compartido tecnologías clave, términos y enfoques que están dando forma a sus respectivas industrias hoy: desde IA y aprendizaje automático hasta código abierto, microservicios y metodologías Scrum. ¡Que empiece el 101 DEV!

Inteligencia artificial, aprendizaje automático y aprendizaje profundo

Por Alberto Massidda, Ingeniero de Producción en Meta

AI, ML y DL

• AI: Es un concepto general que abarca todo lo relacionado con hacer que una computadora o un software sea «inteligente». La IA puede basarse en reglas preprogramadas o en el aprendizaje (la capacidad de aprender de datos y experiencias).
• Machine Learning: Consiste en «permitir que las computadoras aprendan por sí mismas» al darles acceso a un gran conjunto de datos y permitirles establecer reglas y patrones. La salida se genera mediante modelos construidos a través del aprendizaje de datos de entrenamiento.
• Deep Learning (DL): Es un subcampo del aprendizaje automático que imita el principio de funcionamiento del cerebro biológico. Se basa en procesar información a través de múltiples «capas de profundidad». Cada capa de una red neuronal procesa un aspecto diferente de los datos y luego transmite lo que ha aprendido a la siguiente capa. La salida refleja el «punto de vista» de todas las capas.

Modelos

• Modelos Discriminativos en IA: Aprenden límites de decisión a partir de datos de entrenamiento y los utilizan para clasificar nuevas entradas. Aplicables a problemas de decisión y predicción, como generación de precios inmobiliarios, reconocimiento de imágenes y filtrado de spam.
• Modelos Generativos en IA: Estiman la distribución de los datos de entrenamiento, aprendiendo a generar ejemplos que pertenezcan a subgrupos específicos. Se utilizan en diversas aplicaciones, como generación de imágenes, síntesis de voz y traducción automática.

Aprendizaje

• Aprendizaje Supervisado: Algoritmos que aprenden de un conjunto de datos etiquetados. Cada ejemplo de datos consta de una entrada y la salida deseada correspondiente. El objetivo es crear un modelo que, dado una nueva entrada, pueda predecir la salida correcta.

• Aprendizaje no supervisado: Se basa en datos no etiquetados y busca encontrar estructuras o patrones ocultos en los datos. Puede utilizarse para agrupar datos similares (clustering), reducir la dimensionalidad de los datos o descubrir reglas asociativas entre sus características.
  
• Aprendizaje Semi-Supervisado: Se encuentra a medio camino entre el aprendizaje supervisado y el no supervisado. Utiliza un conjunto grande de datos no etiquetados para inducir etiquetas automáticas que luego se utilizan para entrenar un modelo supervisado. Útil cuando las etiquetas de los datos son costosas o difíciles de obtener.

Entrenamiento e Inferencia en IA

• Entrenamiento: Fase en la que un modelo «aprende» de los datos ajustando sus parámetros internos y optimizando su rendimiento.

• Inferencia: Fase en la que se utiliza un modelo ya entrenado para hacer predicciones sobre nuevos datos desconocidos.

Licencias de Software

Por Carlo Piana, Director Único en @Viva Labs

Licencia de Software: Declaración legal que define los términos y condiciones para el uso de un software. Establece los derechos y obligaciones relacionados con el uso del software, además de los derechos y obligaciones establecidos por la ley.

Licencia de código abierto

• Acceso al código fuente: Los usuarios pueden obtener, modificar y distribuir el código fuente libre y transparentemente.
  
• Libertad de uso y distribución: Ofrecen la libertad de utilizar, copiar, distribuir, modificar y redistribuir el software sin restricciones, promoviendo la innovación y el intercambio de tecnología.

• Atribución del autor: Pueden requerir que se dé crédito al autor original del software cuando se utilice o distribuya el código fuente.

• Licencia copyleft: Algunas licencias incluyen cláusulas copyleft, como la GPL (Licencia Pública General de GNU), que requieren que el software derivado o modificado se distribuya con la misma licencia de código abierto del código original.

Licencia Propietaria

• Acceso limitado al código fuente: No proporciona acceso al código fuente del software. Los usuarios reciben solo el producto final compilado y no pueden acceder, ver ni modificar el código fuente. No es de código abierto, es software propietario, aunque sea gratuito.

• Licencia de Pago: A menudo requieren el pago de una licencia. Existen diferentes modalidades de licencia, como licencias para usuarios individuales, licencias empresariales o licencias a tiempo limitado.

¿Y si no aplico una licencia?

Cuando se crea software, la ley reserva todos los derechos al autor. Por lo tanto, si se pretende otorgar permisos para hacerlo de código abierto, es necesario realizar una declaración pública y explícita; de lo contrario, todos los derechos permanecen reservados. Esto no significa que el software se convierta en dominio público: de hecho, el titular de los derechos puede permitir el uso libre solo bajo ciertas condiciones, incluidas aquellas de copyleft. Estas condiciones deben cumplir con la Definición de Código Abierto para considerarse «Open Source».»

Microservicios

Por Mattia Tommasone, Ingeniero Senior de Relaciones con Desarrolladores, Publicidad en Google.

• Modularidad: son componentes independientes que realizan funciones específicas dentro de una aplicación. Cada uno puede ser desarrollado, implementado y escalado de forma separada de los demás.
• Independencia: cada microservicio es autónomo y puede ser desarrollado utilizando diferentes lenguajes de programación, tecnologías y herramientas.
• Comunicación a través de API: los microservicios se comunican entre sí a través de API bien definidas.
• Escalabilidad: permiten escalar de forma independiente las diferentes componentes de la aplicación según las necesidades de carga.
• Aislamiento de fallos: gracias a su naturaleza modular, si uno de los microservicios falla, los demás pueden seguir funcionando normalmente.
• Desarrollo y distribución rápida: la modularidad de los microservicios facilita el desarrollo paralelo y la implementación continua. Cada microservicio puede ser desarrollado, probado y distribuido de forma independiente, acelerando el proceso de desarrollo de la aplicación.
• Facilidad de sustitución y actualización: gracias a la separación de los microservicios, es posible reemplazar uno con una implementación mejor o actualizarlo sin tener que afectar a los demás. Esto simplifica la evolución y la actualización de las diferentes componentes de la aplicación.
• Escalabilidad horizontal: los microservicios pueden ser replicados y distribuidos en varios servidores para distribuir la carga y aumentar el rendimiento de la aplicación.
• DevOps-friendly: la arquitectura de microservicios se adapta bien al enfoque DevOps, ya que facilita la integración continua, la entrega continua y la automatización de los procesos de desarrollo, prueba y distribución.

División en microservicios

• Funcionalidades coherentes: identificar las funcionalidades del sistema que pueden ser aisladas y divididas en microservicios separados. Los microservicios deben ser coherentes, es decir, contener lógicas de negocio relacionadas y proporcionar una unidad funcional distintiva.
  
• Granularidad adecuada: encontrar un equilibrio en el tamaño de los microservicios. Deben ser lo suficientemente pequeños como para garantizar la modularidad e independencia, pero también lo suficientemente grandes como para manejar de manera autónoma una parte significativa de la lógica de negocio.

• Límites del dominio: identificar los límites del dominio, es decir, los límites conceptuales entre las diversas responsabilidades de la aplicación.

• Comunicación e interfaces: definir los modos de comunicación entre los microservicios. Normalmente se utilizan API RESTful, mensajería asíncrona o eventos para permitir la interacción entre los diferentes servicios. Es importante establecer claramente las interfaces y acuerdos de las API para garantizar una comunicación correcta y coherente.

• Aislamiento de datos: considerar cómo manejar el acceso a los datos por parte de los microservicios. Se pueden adoptar diversas estrategias, como la propiedad exclusiva de los datos por parte de un microservicio, la replicación de datos entre los servicios o la adopción de un modelo de consistencia eventualmente consistente.
  
• Gestión de transacciones: evaluar cómo manejar las transacciones entre los microservicios. Las transacciones distribuidas pueden ser complejas de implementar y gestionar. Se pueden adoptar enfoques como la compensación de procesos o el uso de event sourcing y CQRS (Command Query Responsibility Segregation) para garantizar la consistencia de los datos.

• Monitoreo y seguimiento: planificar cómo monitorear y hacer un seguimiento de las solicitudes y respuestas entre los microservicios. Es importante tener visibilidad sobre el rendimiento y las interacciones entre los servicios para diagnosticar y resolver cualquier problema eventual.
• Ley de Conway
  Las organizaciones que diseñan sistemas están destinadas a producir diseños que son réplicas de las estructuras de comunicación de sus organizaciones.

Kubernetes

Para Serena Sensini, Arquitecta Empresarial en Dedalus spa.

• Kubernetes es un sistema de código abierto para la automatización del despliegue, escalabilidad y gestión de aplicaciones contenerizadas. Su objetivo principal es proporcionar un marco para desplegar, mantener y escalar aplicaciones de manera eficiente y confiable en diferentes entornos de alojamiento.

• Master Node: El nodo principal que controla y gestiona el clúster Kubernetes.

• Worker Node: Responsable de ejecutar los contenedores (aplicaciones) en el clúster Kubernetes.

• Kubelet: Agente que se ejecuta en cada nodo y se asegura de que los contenedores se estén ejecutando en un estado deseado.

• Kube-proxy: Mantiene las reglas de red en los nodos para permitir la comunicación entre los diferentes servicios.

• Pod: La unidad más pequeña y simple en Kubernetes, que representa un solo proceso en un clúster compuesto por uno o más contenedores.

• Service: Una abstracción que define un conjunto lógico de pods para permitir la comunicación a través de los componentes de red.
  
• Deployment: Proporciona actualizaciones declarativas para los pods y los ReplicaSets.

• ReplicaSet: Garantiza que se ejecute un número específico de copias de un pod en cualquier momento.

• ConfigMap y Secret: Mecanismos para proporcionar archivos de configuración y/o datos sensibles a los pods.

• Namespace: Permite la separación lógica y la definición de una convención de nomenclatura entre los recursos dentro de un clúster.

• Etcd: Almacena de manera confiable la configuración del estado del clúster.

Big Data

Por Antonio Murgia, Arquitecto de Datos en Agile Labs.

Los datos tienen su propia gravedad. El término «big data» se refiere a un volumen excepcionalmente grande de datos que pueden analizarse para revelar patrones, tendencias y asociaciones. Este concepto está en constante evolución y generalmente se refiere a datos que son tan vastos o complejos que los métodos tradicionales de procesamiento de datos son inadecuados para manejarlos.

Características del Big Data:

• Volumen: Cantidad de datos.
• Velocidad: Velocidad a la que se generan nuevos datos y la velocidad a la que los datos se mueven.
• Variedad: Diferentes tipos de datos estructurados y no estructurados.
• Veracidad: Corrección y confiabilidad de los datos.
• Valor: La capacidad y posibilidad de transformar los datos en valor.

Tipos de Datos

Los datos estructurados están organizados en un formato predefinido y fácilmente analizable (por ejemplo, bases de datos relacionales).

Los datos no estructurados están desorganizados y no siguen una estructura específica, lo que hace más complejo su procesamiento y análisis, como en el caso de textos, imágenes o videos.

ETL y ELT

• ETL (Extract, Transform, Load) son procesos que extraen datos de diversas fuentes, los transforman a un formato compatible y luego los cargan en un almacén de datos para el análisis.
• ELT (Extract, Load, Transform), en cambio, extraen los datos, los cargan primero en el almacén de datos y luego los transforman dentro del propio almacenamiento, a menudo ofreciendo una mayor eficiencia para grandes volúmenes de datos.

Almacén de Datos y Data Lake

Un data warehouse es un sistema centralizado que almacena datos estructurados y, a veces, semi-estructurados, optimizados para análisis rápido e interrogación.

Un data lake es un sistema que puede almacenar grandes volúmenes de datos estructurados y no estructurados, manteniéndolos en su formato bruto hasta que son necesarios para su uso, ofreciendo mayor flexibilidad.

Datos Bronze, Silver y Gold

Los términos bronze, silver y gold se refieren a etapas de refinamiento de datos: los bronze data son datos crudos y no procesados, los silver data son datos limpios y transformados pero no listos para el consumo final, y los gold data son datos refinados, confiables y listos para el análisis y reporting.

Cloud

Por Andrea Saltarello, CTO en Managed Designs.

Public Cloud: Servicios de nube ofrecidos en Internet por proveedores externos, accesibles para cualquier persona que desee suscribirse o adquirirlos.

Private Cloud: Infraestructura de computación en la nube dedicada a una organización específica, ofreciendo mayor control y privacidad.

Hybrid Cloud: Combinación de nubes públicas y privadas, permitiendo el intercambio y la compartición de datos y aplicaciones entre ellas para obtener una mayor flexibilidad y optimización de la infraestructura existente.

Private Cloud vs. On-premises 

Las soluciones en sitio (on-premises) están físicamente ubicadas y gestionadas dentro de las instalaciones de la organización, requiriendo hardware y software dedicado, así como personal de TI para el mantenimiento. La nube privada, por otro lado, ofrece un entorno de computación en la nube dedicado que está alojado de forma remota, gestionado por el proveedor de servicios, pero reservado exclusivamente para la organización, proporcionando mayor escalabilidad y flexibilidad en comparación con una implementación in situ.

Vendor Lock-in 

El «vendor lock-in» en la nube se refiere a la situación en la que una organización se vuelve excesivamente dependiente de un único proveedor de servicios en la nube, dificultando o encareciendo la migración a otro proveedor. Antes de tomar medidas correctivas, es necesario realizar una estimación de riesgos desde el punto de vista de la probabilidad y del costo en caso de materialización. Si estos factores son predominantes, se debe implementar una estrategia para limitar su impacto, incluyendo el uso de estándares abiertos y el diseño de sistemas con portabilidad en mente.

Cloud Governance 

El conjunto de reglas, políticas y procedimientos que una organización implementa para gestionar, monitorear y optimizar el uso de los recursos en la nube.

• Políticas y directrices: Definición de reglas y procedimientos claros para el uso de los servicios en la nube.
  
• Seguridad y cumplimiento: Asegurar que los servicios en la nube cumplan con regulaciones legales y requisitos de seguridad de la organización.
  
• Gestión de costos: Monitoreo y control de los costos asociados con el uso de la nube para evitar desperdicios y sobrecostos inesperados.
  
• Optimización del rendimiento: Garantizar que los recursos en la nube se utilicen de manera eficiente para proporcionar el rendimiento deseado.
  
• Gestión de Riesgos: Evaluación y mitigación de los riesgos asociados con la adopción de la nube, como la disponibilidad y la resiliencia.
  
• Integración e Interoperabilidad: Asegurar que los servicios en la nube se integren de manera uniforme con otros sistemas y tecnologías de la organización.
  
• Monitoreo e Informes: Uso de herramientas para monitorear el uso, el rendimiento y la conformidad de los servicios en la nube, y crear informes regulares para el liderazgo de la organización.
  
• Responsabilidades y roles: Definición clara de roles y responsabilidades dentro de la organización para la gestión y gobernanza de los servicios en la nube.

User Stories e Product Ownership

Por Matteo Guidotto, Senior Growth Product Manager en DaVinci Salute.

Product Owner y Product Manager

El Product Owner tiende a tener un enfoque más táctico y específico del equipo, mientras que el Product Manager tiende a tener un enfoque más estratégico y orientado al mercado. Sin embargo, en algunas organizaciones, los roles pueden fusionarse o tener superposiciones significativas.

Rol guiado por la escucha

• Escuchando atentamente al negocio, el Product Owner puede comprender sus necesidades, problemas y expectativas, fundamentales para definir y priorizar los requisitos del producto.

• El escuchar activamente es esencial para trabajar eficazmente con el equipo de desarrollo, comprender sus desafíos, preocupaciones y sugerencias, así como para asegurar que estén en el camino correcto para alcanzar los objetivos del sprint.

• Al escuchar a otros stakeholders (gerentes, marketing, …), el Product Owner puede asegurarse de que el producto esté alineado con los objetivos empresariales y las estrategias de mercado.

• Una buena escucha es esencial para gestionar y resolver conflictos que puedan surgir entre los stakeholders o dentro del equipo de desarrollo, facilitando la mediación y la búsqueda de soluciones compartidas.

• La escucha construye confianza entre el Product Owner y los stakeholders. Mostrar empatía y consideración puede contribuir a crear relaciones laborales positivas y productivas.

Definition of Ready (DoR)

La Definition of Ready establece los criterios que un elemento del backlog del producto debe cumplir antes de considerarse listo para ser incluido en un sprint.

• Claridad de los requisitos, acuerdo sobre el alcance, estimaciones (cuando estén presentes), solución de todas las dependencias.

La DoR ayuda a prevenir malentendidos y retrasos en el trabajo del sprint, asegurando que el equipo comience con expectativas e información claras.

Definition of Done (DoD)

La Definition of Done, por otro lado, establece los criterios que un elemento del backlog del producto debe cumplir para considerarse completado, por ejemplo: código escrito y probado, código revisado, documentación completa, clientes y usuarios finales satisfechos.

La DoD garantiza que cada elemento completado cumpla con un estándar de calidad acordado y que esté realmente listo para ser lanzado, si es necesario.

Riesgos de la Definition of Ready (DoR)

Una DoR demasiado rígida o detallada puede reducir la flexibilidad y la capacidad del equipo para adaptarse a los cambios. Puede interpretarse de manera que solo el Product Owner es responsable de la preparación de los elementos del backlog, lo que podría reducir la colaboración y la discusión dentro del equipo sobre estos elementos. Puede dar una sensación de falsa seguridad, haciendo creer que, si se cumplen todos los criterios, no habrá problemas durante el desarrollo, lo cual no siempre es cierto.

UI e UX Design

Por Davide Di Pumpo, Design Technologist en Amazon, y Paul Romero, UX & Service Designer.

Design

• Global Process: Es un proceso más amplio que va más allá del simple diseño. Incluye la planificación, la definición de objetivos, la resolución de problemas, la consideración de las necesidades del usuario y la implementación práctica de un concepto o producto.
• Orientado a los Objetivos: Se centra en la obtención de resultados específicos o en el cumplimiento de un objetivo. Puede incluir el pensamiento estratégico, la investigación de usuarios, la optimización funcional y la evaluación del rendimiento.
• Involucra diversas competencias: Suele requerir una gama más amplia de habilidades, que incluyen ingeniería, arquitectura, psicología del usuario, sostenibilidad y mucho más.

El proceso:

1. Investigación de mercado y del usuario
2. Análisis y Definición de Requisitos: Definición de casos de uso, Creación de perfiles de usuarios
3. Ideación y Diseño Conceptual: Tormenta de ideas, Prototipado, Pruebas.
4. Diseño de la Interfaz de Usuario (UI): Creación de esquemas, Diseño visual, Creación de prototipos interactivos.
5. Pruebas con Usuarios e Iteración: Evaluación con usuarios, Análisis de resultados e iteraciones.
6. Desarrollo e Implementación: Colaboración con el equipo de desarrollo, Pruebas y control de calidad.
7. Lanzamiento y Monitoreo: Lanzamiento del producto, Monitoreo de la experiencia del usuario.

Nota importante: Según el proyecto, algunas de estas fases pueden omitirse.

Atomic Design

• Átomo: Son los elementos básicos de la interfaz de usuario, como botones, campos de texto, iconos o colores. Son componentes simples y reutilizables que actúan como bloques fundamentales en la creación de elementos más complejos.
• Molécula: Son grupos de átomos que trabajan juntos para formar componentes más avanzados. Un módulo de entrada de datos podría ser una molécula compuesta por un campo de entrada, un botón y una etiqueta.
• Organismo: Los organismos son componentes de interfaz de usuario más grandes y autosuficientes. Representan secciones complejas de la interfaz como barras de navegación, encabezados o tarjetas que contienen diversas moléculas y átomos que trabajan juntos.
• Template: Los templates proporcionan una estructura básica para las páginas de la interfaz de usuario. Definen la disposición general de los organismos y moléculas en una página, pero no contienen contenido específico.
• Páginas: Las páginas representan las instancias concretas de las interfaces de usuario completas, donde se inserta el contenido específico. Son la manifestación final del diseño e incorporan todos los demás elementos, desde los templates hasta los organismos, moléculas y átomos.

Scrum

Scrum es un marco de trabajo ágil basado en el empirismo y el pensamiento Lean, presentado por Fabio Panzavolta, Scrum Master Independiente.

Fundamentos

• Empirismo: la toma de decisiones se basa en la experiencia y los hechos. Transparencia, inspección y adaptación son los tres pilares del empirismo.
• Lean Thinking: se centra en crear valor lo más rápidamente posible y reducir el desperdicio.

Para más información, puedes visitar www.scrumguides.org.

Valores

Scrum se practica en un entorno de Seguridad Psicológica.

• Coraje: afirmar las propias ideas, no ocultar hechos o información relacionada con el producto, respetar los principios y elementos de Scrum.
• Enfoque: concentrarse en hacer solo lo que es útil para la creación de valor, en el momento más oportuno. Estar presente plenamente en cada evento Scrum.
• Apertura: abrazar todas las ideas, de cualquier persona, sin juicio y resistir a lo que la propia experiencia podría sugerir. Probar cosas que de otra manera no se probarían.
• Respeto: hacia todas las personas que nos rodean, como individuos competentes y por todas las ideas y propuestas útiles para mejorar el producto.
• Compromiso: dar siempre lo mejor para alcanzar los objetivos establecidos, comprometerse a respetar los eventos Scrum.

Puedes obtener más detalles en www.thescrumvalues.org.

Responsabilidades

• Product Owner: Responsable de maximizar el valor del producto y gestiona el Product Backlog.
• Desarrolladores: Profesionales que crean el producto o servicio, autoorganizados y multidisciplinarios. Se comprometen a entregar incrementos de producto completos y listos para su lanzamiento al final de cada Sprint.
• Scrum Master: Responsable de la eficacia del Scrum Team, facilita el proceso Scrum, asegura que se respeten las reglas y prácticas del marco, ayuda al equipo Scrum a eliminar obstáculos y resolver problemas que podrían impedir el logro de los objetivos del Sprint, promueve la mejora continua y fomenta el crecimiento y la madurez del equipo.
• Scrum Team: Compuesto por Product Owner, Desarrolladores y Scrum Master, es autogestionado y multifuncional.

Artefactos

• Product Backlog: Refleja la estrategia del Product Owner y es una lista emergente de trabajo en el producto. Contiene el Product Goal.
• Sprint Backlog: Un subconjunto del Product Backlog que representa las actividades y elementos seleccionados por los Desarrolladores para un Sprint específico. Contiene el Sprint Goal.
• Incremento: Un paso adelante hacia el logro del Product Goal. Debe cumplir con la Definition of Done, es decir, estar completo, probado y listo para su lanzamiento en producción.

Eventos

• Sprint: Es el evento central de Scrum, que contiene todos los demás eventos y proporciona la frecuencia regular de inspección y adaptación.
• Sprint Planning: Evento en el cual el Scrum Team colabora para establecer el Sprint Goal, prever los elementos más importantes del Product Backlog y definir. Los Desarrolladores proporcionan detalles sobre el trabajo necesario para completar al menos los primeros elementos seleccionados del Product Backlog.
• Daily Scrum: Evento diario de los Desarrolladores, que permite planificar las próximas 24 horas y comprender si el trabajo realizado aumenta las probabilidades de alcanzar el Sprint Goal.
• Sprint Review: Evento informal y colaborativo en el que el Scrum Team y los Stakeholders inspeccionan el incremento y proporcionan comentarios útiles para la adaptación del Product Backlog.
• Sprint Retrospective: El Scrum Team reflexiona sobre el último Sprint, identifica lo que salió bien y lo que se puede mejorar, y planifica acciones correctivas para el próximo Sprint.

En conclusión, estas valiosas aportaciones de los desarrolladores que participaron de GitBar revelaron un 101 DEV que devela el panorama dinámico y emocionante en constante evolución que tenemos en tech. Desde la inteligencia artificial hasta las metodologías ágiles, se vislumbra un futuro impulsado por la innovación y la colaboración. Que estas ideas inspiren y guíen a la comunidad de Codemotion en su continuo viaje hacia el progreso tecnológico. ¡Que el código siga siendo un lenguaje universal que une a nuestra comunidad en constante crecimiento!

Únete a nuestra comunidad

¿Quieres orientar tu carrera para convertirte en un experto en ciberseguridad? En nuestra plataforma de Talent puedes encontrar la forma de llevar tu carrera al siguiente nivel. Entra en nuestra web y encuentra tu trabajo ideal. Échale un vistazo.

Ser parte de la comunidad de Codemotion te permitirá potenciar tu experiencia y enfrentar nuevos desafíos que impulsarán tu carrera. Aprenderás nuevas habilidades técnicas y crecerás junto a otros miembros mediante el intercambio de opiniones y la creación conjunta. Tenemos dos comunidades para ti según tu experiencia:

Si eres wanna-be-dev,  junior-dev o early-mid-dev nuestra comunidad de Discord es para ti. Allí encontrarás recursos, eventos, formación, muchos compañeros de viaje y beneficios exclusivos. Súmate aquí.

Si eres late-mid-dev, senior-dev, Tech Lead o CTO nuestra comunidad de Telegram es para ti. Allí encontrarás el mejor networking, artículos high-tech, debates de tendencias tech y beneficios exclusivos. Súmate aquí.

¡Nos vemos en Codemotion!