¿Qué pasa cuando alcanzas esa meta profesional tan deseada (como ser Senior) y, de pronto, sientes que no sabes hacia dónde avanzar? En este especial de Año Nuevo, te comparto mi propia experiencia enfrentando un bloqueo tras mi ascenso, el impacto de tomarme un período sabático y cómo descubrí herramientas (como Notion) para redefinir mis objetivos de una forma más sana y consciente.

Hablaremos de:
• Cómo evitar la “trampa” de las metas y cuidar tu bienestar en el proceso.
• La diferencia entre sentirte perdido y creer que “no vales lo suficiente”.
• Por qué la organización y el autoconocimiento pueden impulsar tu siguiente gran paso.

¿Te gustaría compartir tu experiencia o sugerir un tema para el podcast? Visita remusrd.com o escríbeme a [email protected]. ¡Y si disfrutas este contenido, suscríbete a Programar es simple y déjame 5 estrellitas en Spotify para seguir creciendo juntos en este nuevo año!

(0:00) - Introducción

Vídeo donde José Elías da su opinión: https://www.youtube.com/watch?v=xRKx3TJqkbQ

Episodio anterior acerca del podcast: https://open.spotify.com/episode/79f4VAQsn9Ffia6F9IErQR?si=-ixoYBpgQeaZQuiSgyJzjA

Estudios a los que les he echado un ojo para este podcast:

La gente prefiere el trabajo en remoto: https://www.hrotoday.com/news/only-5-of-employees-prefer-working-in-the-office/#:~:text=The report finds that 63,a good boss (48%25).

Mi email: [email protected]

En este episodio hablamos un poco sobre lo que a veces puede llegar a ser la mala práctica de crear soluciones complejas porque es fácil en vez de evitarlo y hacer algo simple ó no hacer nada.

Recordad que podéis contactarme a través de: https://remusrd.com.

En este episodio de programar es simple hablamos con Juan Andrés Núñez, desarrollador web y autor de https://wmedia.es/. 

Es una conversación informal en la que tocamos temas como la obsesión con la productividad ó dedicarse a la formación en el ámbito tecnológico.

Recursos mencionados en el episodio:

Libro Mastery: https://www.amazon.es/Mastery-Robert-reene/dp/014312417X

Jeffrey Way: https://laracasts.com/@JeffreyWay

En este episodio hablamos un poco sobre el estado del front end, os traigo a Emanuel que tiene más idea que yo y hablamos de Angular, React, Vue y otros temas que han ido saliendo sobre la marcha como Github Copilot.

En este episodio os cuento una conversación que tuve con una amiga el otro día, hablamos un poco de estudios.

Recordad que podéis contactarme a través de https://remusrd.com.

En este os cuento acerca de una de las últimas entrevistas que hice(como entrevistador).

Normalmente, hacemos una prueba técnica(coding challenge) la cual consiste en hacer un pequeño servicio que cumple una serie de requerimientos a través de un REST API.

Intro a arquitecturas limpias, tienes una capa principal dónde está el dominio, que son los objetos que tendrán la lógica de negocio, yo cuando he trabajado con este tipo de arquitecturas, dominio y aplicación van de la mano, entonces, los casos de uso/servicios son los que están en el centro de la arquitectura, sólamente las piezas interiores conocen sobre las exteriores, como exteriores tenemos los repositorios, tenemos los controllers, etc, que conocen de los casos de uso pero no al revés, yo desde un caso de uso, no sé si me llama un controller ó un evento ó lo que sea, normalmente los dividimos por inbound/outbound, controller sería un inbound y repository sería un outbound.

La persona en cuestión tenía todas las validaciones dentro del objeto de la petición al servicio. Llegando a hacer saber al caso de uso acerca de JSON por ejemplo.

Tipos de validación : cliente(Front end), servidor(API, dominio)

Cliente: Validación de formularios, feedback usuario etc.

La API valida la forma del mensaje que se recibe, por ejemplo que una fecha sea una cadena ó que una cantidad sea un número, se podrían llegar a validar por ejemplo en el caso de una transferencia que la cantidad sea positiva, si eso tuviese sentido a la hora de exponer nuestro API.

El dominio, normalmente, valida las reglas de negocio, por ejemplo, si quieres hacer una transferencia, que tengas saldo suficiente, normalmente en cómo suelo montar las arquitecturas de los servicios, si necesitas acceder a la bbdd seguro que es una validación de dominio.

Recordad que podéis contactarme a través de https://remusrd.com.

Este episodio fue grabado en twitch: https://www.twitch.tv/remusrichard.

Cuando empecé en mi equipo, el primer cometido, antes de desarrollar nada, era mover la lógica de aplicación que había en un monolito a microservicios.

En este episodio os cuento sobre:

→ la situación en la que estábamos, cómo se llegó a esta decisión y qué herramientas teníamos

→ Mi experiencia saliendo del monolito(Episodio anterior, hablábamos de qué approach elegir. https://open.spotify.com/episode/3ErtKuvhTxcHClZebZibCO?si=c9882cf7bd644d46 )

→ Empecemos con el monolith

    → No tienes un dominio claro

    → No tienes dinero/tiempo para gastar

    → Quieres validar validar rápidamente un modelo negocio

    → pocas personas van a contribuir

→ Directamente a microservicios

    → Tienes el dominio claro, te viene dado, por ejemplo un banco, dominio de cuentas, tarjetas etc...

    → Tienes inversión externa.

    → Las suficientes manos para crear un sistema distribuido en general, pipelines, infraestructura(Kubernetes), trazabilidad, es más complejo de       saber lo que está pasando

    → Mucha gente que si no tendría que commitear al mismo repo

    → Conocimientos técnicos/dominio para evitar un monolito distribuido

→ Qué elección tomar

    → Norma general, empezar por monolito, partir después, probablemente no sepas por dónde partir

    → separar dominios a nivel de código, no a nivel de aplicaciones. Pensar en las razones que tiene una cosa/funcionalidad para cambiar.

    → Ejemplo con notificaciones.

Este episodio fue grabado en twitch: https://www.twitch.tv/remusrichard