Programar es simple

En este episodio, exploramos la frustrante brecha entre el potencial de las herramientas modernas y las restricciones corporativas que nos impiden usarlas. No es solo un problema sobre IA, exploramos los matices y las posibilidades.https://www.remusrd.com

ResumenEn este segundo episodio, Richard explora una de las ansiedades más profundas de nuestra era digital: ¿está la IA reconfigurando silenciosamente nuestra forma de pensar?Lo que comienza como una simple reflexión sobre un "músculo mental atrofiado" se transforma en una exploración fascinante sobre cómo la memoria perfecta de la IA puede atraparnos en burbujas personalizadas que amplifican nuestros propios sesgos.Pero este no es otro episodio apocalíptico sobre los peligros de la tecnología. En cambio, Richard presenta un marco práctico para transformar la IA de oráculo complaciente a socio intelectual desafiante, recuperando así nuestro poder de pensamiento crítico.El verdadero peligro no es lo que pareceNo es la pérdida de habilidades técnicas lo que debería preocuparnos, sino quedar atrapados en cámaras de eco personalizadas donde la IA solo nos dice lo que queremos escuchar.El método de colaboración consciente (3 pasos)Planifica con la IA como si fuera un colega de equipoDesafía su propuesta con preguntas incómodas y contra-argumentosValida mediante revisión humana, manteniendo siempre el contexto y la conexión finalElige tu rol: Explorador vs. Residente¿Usarás la IA para aventurarte en territorios desconocidos del conocimiento? ¿O te conformarás con habitar el mundo predecible y cómodo que construye para ti?La duda como superpoderEn una época de respuestas instantáneas e infinitas, nuestra capacidad para dudar, cuestionar y buscar perspectivas humanas alternativas se convierte en nuestra ventaja competitiva más valiosa.

¿Qué pasa cuando un senior developer puede producir como diez? ¿Dónde quedan los juniors? En este episodio de 'Programar es Simple', exploro el vértigo que sentí al leer que la IA escribirá el 90% del código en meses, no años: - ¿Por qué algunos ven un precipicio y otros solo otro escalón? - ¿Cómo aprenderá la próxima generación sin bugs que debuggear? - ¿Qué le decimos a quien quiere empezar en tech? Si la IA escribe el código rutinario, lo que queda es entender contexto, tomar decisiones, ver más allá del teclado. Pero, ¿cómo desarrollas esas habilidades sin pasar primero por lo básico? https://remusrd.com

Todo el mundo critica el 'feedback sándwich', ¿pero es siempre un error? En este episodio de 'Programar es Simple', reacciono a una crítica feroz que vi online y profundizo: ¿Por qué falla tanto esta técnica (confusión, falsedad, desconfianza)? ¿Hay contextos (alta confianza, baja cultura de feedback, intención torpe) donde, aunque no sea ideal, persiste o su impacto es menor? Exploramos los matices y defendemos que, más allá de cualquier fórmula, la clave del buen feedback está en la conexión real, la confianza y la claridad. https://remusrd.com

¿Qué haces cuando una evaluación pone en duda tu impacto técnico, a pesar de haber pedido claridad y haber trabajado en ello?En este episodio de Programar es Simple, te cuento cómo viví una evaluación de desempeño que removió mucho más que métricas: cuestionó mi lugar, mis valores y mi decisión de seguir en la empresa. Pero también fue el inicio de un proceso de reflexión más amplio sobre cómo equilibrar lo que se espera de ti con lo que tú esperas de tu vida.Hablaremos de:El momento en que decidí parar una reunión para procesar lo que sentía.Por qué elegí quedarme… y cómo hice las paces con una métrica que no me representaba del todo.Qué es el “portafolio de valores” y cómo me ayuda a equilibrar vida y trabajo.Cómo la IA entró en la ecuación y me ayudó más de lo que esperaba.¿Has vivido una evaluación difícil o una desconexión con los valores de tu entorno laboral? ¿Qué hiciste tú? Escríbeme a ⁠[email protected]⁠ o cuéntamelo en ⁠remusrd.com⁠.Y si te gusta este contenido, suscríbete a Programar es Simple y déjame 5 estrellitas en Spotify. ¡Me ayudas muchísimo!

¿Recibiste un feedback que te hizo dudar de tus capacidades, incluso como senior? En este episodio de Programar es Simple, comparto una historia personal sobre ese 'golpe de inseguridad' y cómo lo afronté. Desmontamos por qué duele tanto la crítica (¡no es un bug, es feedback!), aprendemos a separar nuestras acciones de quiénes somos y te doy pasos prácticos, incluyendo el método SMART, para transformar comentarios ambiguos en un plan claro de crecimiento.Hablaremos de:La psicología detrás del 'dolor' del feedback.Cómo proteger tu identidad sin ignorar áreas de mejora.Pasos para pedir claridad ante comentarios difusos.Aplicar SMART para crear acciones concretas y medibles.¿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!

¿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 (0:46) - Acerca del podcast (1:50) - Supervisión y productividad en remoto (3:33) - Medición de la productividad en el sector tecnológico (5:42) - Contratación global y sus retos (8:20) - Percepción de la motivación y el "colmillo" (9:34) -¿Qué pienso yo? Notas adicionales y enlaces. 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: https://journals.e-palli.com/home/index.php/ajebi/article/view/1088 https://revistas.udes.edu.co/aibi/article/view/effects_of_remote_working_in_fortune_500_global_companies 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 Redes de Juan: https://wmedia.es/ Recordad que podéis contactarme a través de: https://remusrd.com.

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. Recordad que podéis contactarme a través de https://remusrd.com.

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 → Cómo mantuvimos la aplicación funcionando igual que antes antes de que migrásemos cada cliente    → El proceso de migración, por qué falló aunque fuese transaccional   → Qué podríamos haber hecho para arreglarlo Recordad que podéis contactarme a través de https://remusrd.com . Este episodio fue grabado en twitch: https://www.twitch.tv/remusrichard

→ Mi experiencia saliendo del monolito(Episodio anterior, hablábamos de qué approach elegir. https://open.spotify.com/episode/3ErtKuvhTxcHClZebZibCO?si=c9882cf7bd644d46 ) → Es una historia que suelo contar en las entrevistas cuando me preguntan por un fuck up(siguiente episodio) → Esto empezó cuando teníamos que sacar a microservicios cierta parte del funcionamiento del monolito → No se podían perder datos, había que tener las dos opciones siempre disponibles, es decir, ciertos clientes iban a usar una versión y el resto la otra(beta group) → No fue un desacoplamiento 100% del monolito, el monolito seguía recibiendo todas las peticiones, actuando como un api gateway, hacía autorización/autenticación y comprobaba si estabas en la beta para saber qué código ejecutar, si llamar al nuevo mS ó ejecutar el código php(feature flags → [<https://open.spotify.com/episode/4nyU3pzk7SIvtpIVFw71dB?si=MvUdVzOKS-mzAP5Z7o4MdQ>](<https://open.spotify.com/episode/4nyU3pzk7SIvtpIVFw71dB?si=MvUdVzOKS-mzAP5Z7o4MdQ>)) → La información que no se tenía en el microservicio, por ejemplo datos de empleados, se le forwardeaba al microservicio en la petición ó respuesta, ejemplo, si mi mS tuviese un id de propietario de una cuenta de banco, el monolito antes de pasarselo al front end de vuelta, le añadía el nombre y datos del propietario que necesitaba mostrar. El problema de esto es el acoplamiento que se crea. → Siguiente iteración, para quitar esta dependencia con el código de php, cada vez que hacíamos un cambio al contrato ó añadíamos un endpoint, teníamos que modificar el código en los dos lados. Primero, añadimos una conexión directa a la bbdd del monolito(en este caso era una réplica de sólo lectura) y ahí ya sacábamos diréctamente  todos los datos necesarios para retornar al front end. → Última iteración, fue empezar a tener las tablas de las que dependíamos, por ejemplo empleados, duplicadas en nuestra bbdd del microservicio para ser autónomos.     → Empezar a consumir los eventos de las diferentes entidades, como por ejemplo cuando se crea un empleado, actualiza ó se borra, de esa forma, tendríamos los datos en nuestro lado. Pero aquí faltaban los eventos de antes(SQS y SNS no son event store) entonces había que recrear estos eventos, ir a través de toda la tabla de empleados, y emitir un evento por cada uno para que esos datos se actualicen en nuestro lado. Recordad que podéis contactarme a través de https://remusrd.com . Este episodio fue grabado en twitch: https://www.twitch.tv/remusrichard

→ 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. Recordad que podéis contactarme a través de https://remusrd.com . Este episodio fue grabado en twitch: https://www.twitch.tv/remusrichard

Hablemos de qué es un refactor → Cambios en el código que son demasiado pequeños para aportar valor, pero en su conjunto sí que aportan. Haciendo estos cambios de forma pequeña y utilizando otras metodologías como el paralell change(debate para otro episodio), evitamos introducir bugs, siempre ayudándonos de tests. Os cuento la historia sobre mi manager, cómo nos pregunta sobre un refactor que planteamos, era una tarea en la que teníamos que compartir un documento entre varias personas, pero la arquitectura en general de la aplicación, no estaba pensado para ello, había algunos tipos que sí que se podían compartir y otros que no, entonces para no ensuciar todo el código con ifs por todas partes, decidimos sacar toda esta lógica a otro servicio, os cuento más en otro episodio, pero quería llegar al punto de que esto no era un refactor, era una reimplementación ó un rewrite entero de las funcionalidades que ya teníamos. La productividad de tu IDE → algo de lo que podría estar hablando horas, pero hoy respecto a los refactorings, saber atajos como por ejemplo en Intellij Idea, escribir .val después de una expresión y eso te generará una variable, a la hora de escribir tests o código productivo es súper útil. Yo soy un friki de este tipo de trucos, por ejemplo lo cursores múltipls, atajos para casi cualquier refactor etc, pero si usas intellij por ejemplo, con saber un par de atajos como por ejemplo del doble shift para buscar cualquier cosa ó cmd + shift + a para buscar caulquier acción evitarías que me lloren los ojos y que me ponga nervioso mientras escribes todo letra a letra. Normalmente no debería afectar al alcance que tenemos, por ejemplo yo cuando refactorizo, alguna cosilla que no me gusta, suelo hacerlo, ver que todo funciona pasando todos los test. https://refactoring.guru/es

Hoy os cuento un par de historias de amigos que siempre me hablan que desplegar un viernes es un dolor y que les da miedo, os cuento mi visión acerca del tema y lo que creo que deberíamos mirar.  Recordad que podéis contactarme a través de https://remusrd.com .

Hoy os cuento un poco mis impresiones sobre el último proyecto que me han propuesto, cosas que a nivel de tecnología creo que no tienen mucho sentido y otras que me llaman la atención. Recordad que podéis contactarme a través de https://remusrd.com .

Hoy hablamos de los feature flags o feature toggles y cómo los he ido aplicando a lo largo de mi carrera.  Quizás un punto que se me ha pasado comentar es el overhead que implica hacer release toggles a nivel de código, porque tu código tiene que poder comportarse igual que antes de implementar el cambio además de cómo se comportaría con la nueva feature. Recordad que podéis contactarme a través de https://remusrd.com .

Hoy hablamos sobre el trabajo el remoto, cómo ha sido impulsado por la pandemia y cómo este ha impactado mi carrera, además, os cuento algunas ventajas y desventajas que he ido experimentando a lo largo de mi carrera y algunos consejos sobre cosas que me han funcionado.  Recordad que podéis contactarme a través de https://remusrd.com .

En los últimos años, me he estado metiendo en el tema de freelancing, en este episodio, os cuento cuál ha sido mi experiencia trabajando como autónomo, cuánto he cobrado y algunos consejos para no morir en el intento. Recordad que podéis contactarme a través de https://remusrd.com .

Llevo ya un tiempo entrevistando todo tipo de desarrolladores, seniors, leads y profesionales, el otro día cuando entrevisté al último, me extrañó cuando me dijo que el candidato era un buen fit cuando, cosas tan importantes para mí como el testing o arquitecturas limpias, para él no lo era. 

Hoy es mi cumpleaños, me gustaría dejar por un momento el síndrome del impostor y hablar un poco de cómo ha cambiado mi vida laboral últimamente. Recordad que podéis contactarme a través de https://remusrd.com .

A mí enseñar me gusta mucho, hace poco tuve la oportunidad de impartir un bootcamp de desarrollo de software, en este episodio os cuento un poco acerca de ello, acerca de como llevo compatibilizarlo y cómo es facturar cuando tienes dos trabajos en España entre otras cosas. Recordad que podéis contactarme a través de https://remusrd.com .

En este podcast hablamos de los salarios que son normales cuando trabajas para empresas de renombre o que buscan talento con unos requerimientos muy específicos, os cuento mi punto de vista y lo comparo un poco con los salarios de otras profesiones. Recordad que podéis contactarme a través de https://remusrd.com .

Como os comenté en episodios anteriores, algo en lo que quiero trabajar personalmente, es los problemas algorítimicos y de estructuras de datos que se piden en las entrevistas más complicadas, para ello, voy a hacer una serie de episodios donde os cuento cómo resolvería yo esos problemas y otras soluciones válidas posibles para pasar estas entrevistas. Aquí tenéis el código de la solución comentada  https://gist.github.com/RemusRD/1e63820493036f8240c6c020777dc7a3 . Recordad que podéis contactarme a través de https://remusrd.com .

En este episodio os comparto mi idea de cuándo hay que refactorizar, que es constantemente, creo que refactorizar solo cuando vayas a cambiar el código en sí es peligroso. Recordad que podéis contactarme a través de https://remusrd.com .

Hacer entrevistas para puestos técnicos, como ya sabéis no es cosa fácil, pero además, hay ciertas situaciones que lo hacen aún más frustrante, en este episodio, os cuento un par de situaciones que he tenido recientemente que no han sido precisamente cómodas. Recordad que me podéis encontrar en www.remusrd.com

Más de una vez, me he encontrado en la situación de que las herramientas que existen para facilitar el proceso de desarrollo de software, en vez de hacerlo, oponen más resistencia en su lugar, en este episodio, os cuento un poco cómo pienso yo acerca de ello y un par de situaciones recientes.

Hoy os cuento sobre las cosas que valoro ahora contrastándolo con lo que os conté en el primer episodio, entrevistar gente no es fácil pero pequeños gestos como justificar las decisiones ó dar feedback loops más cortos son algunas de las cosas que más valoro.

Cuando empecé a trabajar, empecé en un producto, en una empresa que directamente desarrollaba ese software, después, al tiempo, entré en una consultora donde aprendí muchísimo, pero tenía otros problemas que comento en este episodio, ahora mismo, no buscaría nunca un trabajo de consultor, y es que, hay cosas de hacer producto que se pierden por el camino. Podéis dejarme algún comentario en iVoox ó Itunes ó mandarme un email si queréis en [email protected].

En este episodio os cuento una historia de cómo sobrenormalizar una base de datos nos llevó a gastar bastante tiempo en ponerla a punto, también, cómo esto puede afectar al rendimiento pero como punto más importante, por qué deberíamos modelar una base de datos en base a los patrones de acceso a ella y evitar caer en malas prácticas, por último tocamos un poco de nosql que es de dónde he sacado yo esta forma de pensar en la que guardas los datos de la forma más parecida a lo que quieres consumir(siempre respetando el dominio).

En este podcast os cuento un poco acerca de por qué no llegué a hacer una carrera y por qué divago un poco sobre el uso de las matemáticas en la mayoría de trabajos que he tenido.

El pair programming es una práctica que en mi trabajo siemrpe me ha aportado mucho, tanto para crecer técnicamente como en otros muchos aspectos.

Seamos realistas, todo el mundo usa Git. En este episodio, os hablo de mi experiencia usando Git y cómo influye en mi trabajo además de contaros las formas en las que más cómodo me siento trabajando con ello. Hablaremos de git-flow, github-flow y trunk-based.  Aquí tenéis el link del vídeo que menciono https://www.youtube.com/watch?v=ykZbBD-CmP8. Recordad que podéis contactarme a través de https://remusrd.com .

Una vez terminas los estudios, buscar trabajo a veces se hace algo difícil, no es el caso cuando eres programador, hay muchísima demanda y poca gente capacitada para ejercer los puestos. Se dice que cada 5 años se dobla el número de programadores, por lo que siempre la mitad de los posibles candidatos a un puesto no tendrán más de esta experiencia para acceder al puesto. En este episodio, os hablo de los procesos que he tenido yo, que han sido unos cuántos en los últimos años, además de esto, os comento los procesos que más me han gustado y en los que más valorado me he sentido, cosa que yo personalmente, considero muy importante. P.S: Por favor! Hago un llamamiento para que si alguien es tan amable, me de un poco de feedback acerca de este episodio :) Recordad que podéis contactarme a través de https://remusrd.com .