Tengo una newsletter donde doy consejos diarios y cuento experiencias relacionadas con escribir software de calidad usando buen diseño de software, testing y técnicas de refactoring.
Suscríbete desde el link de mi perfil
Dev vs Tester
Tengo una newsletter donde doy consejos diarios y cuento experiencias relacionadas con escribir software de calidad usando buen diseño de software, testing y técnicas de refactoring.
Suscríbete desde el link de mi perfil
Es importante establecer un sistema de seguimiento real y sincero, en el que los empleados puedan expresar de verdad sus inquietudes.
Y no lanzar ofertas de última hora, regateando como si estuviéramos en un mercadillo.
Preocuparte por tus empleados cuando están dentro, no cuando deciden salir y renuncian.
Pero de aquí se puede sacar una gran lección:
La "retención" del talento no consiste en ofrecer soluciones de prisa y corriendo cuando alguien YA ha decidido marcharse.
Se trata de tener visión de futuro.
"Si no estás satisfecho con tus responsabilidades actuales, podemos redefinir tu rol dentro de la empresa"
Pero de nuevo no era el motivo.
¿Sabes cuál era el motivo?
Tenían una cultura y valores muy alejada de los míos
Bien, pues, esta fue la conversación que tuve con mi mujer hace 14 años, cuando renuncié al puesto de trabajo que tenía en ese momento.
Dos días después la CEO de la empresa me llamó a su despacho.
Y me dijo:
"¿Qué podemos hacer para que te quedes?
Si es un tema de compensación, podemos ajustar tu salario."
"Que una persona como tú renuncie supone un fracaso para mí como manager",
Un detalle, pero el dinero no era el problema.
Para mi jefe, ha sido toda una sorpresa
No se lo esperaba.
Pero ya no hay marcha atrás.
¿Sabes qué me ha dicho?
Pues tengo que contarte una cosa.
Acabo de renunciar.
He presentado mi baja voluntaria.
🧵 👇
Tengo una newsletter donde doy consejos diarios y cuento experiencias relacionadas con escribir software de calidad usando buen diseño de software, testing y técnicas de refactoring.
Suscríbete desde el link de mi perfil
El resto… puede esperar.
Y curiosamente, cuando haces eso,
las cosas empiezan a mejorar sin dejarte la salud por el camino.
Con el tiempo entendí que no va de solucionar todos los problemas.
Eso es imposible.
Va de saber elegir el mejor problema a resolver en cada momento.
De decidir qué problema si merece tu energía y cual no.
Salva lo que más daño hace en este momento.
Lo que bloquea al proyecto.
Otro mensaje.
Otra urgencia que “no puede esperar”.
Al final el que te apagas poco a poco eres tú.
Rápido.
Disponible.
Siempre.
Y claro, eso te da fama de “este tío responde”.
Pero también te deja hecho polvo y no resuelves igual.
Porque cuando intentas arreglarlo todo, nunca paras.
Siempre hay otro fuego.
Si pudiera volver atrás y decirme algo sería esto:
No intentes apagar cada fuego
Hubo una época en la que trataba de apagar todos los fuegos posibles.
Que si algo ardía, yo tenía que estar ahí.
🧵 👇
Una formación que es exclusiva para suscriptores de mi newsletter.
Te puedes suscribir a mi newsletter desde el link de mi perfil para poder apuntarte a la lista de espera de la siguiente edición.
Preguntándome si conocía a alguien que se hubiera formado conmigo en Clean Architecture que buscara trabajo.
Antes de pensar que algo no funciona, piensa si lo mismo eres tú quien no lo está aplicando bien.
Estos code smells los explico en mi formación.
Efectivamente, había aplicado Clean Architecture como no es.
Cometiendo todos los code smells posibles que existen.
Les hice un informe detallando todos y cada uno de sus problemas.
Me volvió a escribir a los meses.
Emocionado por los resultados.
¿Podía haberle dicho que llevaba usándolo más de 10 años?
¿En proyectos pequeños?
¿En proyectos medianos?
¿En proyectos grandes?
Sí, pero no lo hice.
Le propuse una auditoría, revisándole su proyecto.
A los pocos meses me escribió para decirme que Clean Architecture no funcionaba.
Le dije que con Clean Architecture pueden pasar varias cosas.
Aplicarlo cuando no toca.
Aplicarlo donde no toca.
Aplicarlo como no es.
Pero no tenía sentido decir que no funcionaba.
No voy a entrar a debatir cada.
No es el momento.
No es el lugar.
Pero sí voy a detallar sobre una.
Una vez trabajé con un cliente que, después de mi formación, empezó a usar Clean Architecture.
Esto no es para proyectos pequeños.
Esto no es para proyectos medianos.
Esto no es para proyectos grandes.
Podría escribir un libro con todas las que me han dicho.
Con MVP es suficiente.
Con MVVM no necesitas más.
Con BLoC ¿qué sentido tienen los casos de uso?.
Sigo.
En frontend no debería estar la lógica.
La lógica en backend.
Sigo.
La base de datos nunca se cambia.
Hay casos de uso de solo una línea.
Si haces un CRUD es innecesario.
Sigo.
He escuchado de todo sobre Clean Architecture.
Es sobreingeniería.
¿Para qué usas un framework si luego te desacoplas?
Se desaprovechan las cualidades del framework.
Sigo.
Clean Architecture no funciona
🧵 👇
Tengo una newsletter donde doy consejos diarios y cuento experiencias relacionadas con escribir software de calidad usando buen diseño de software, testing y técnicas de refactoring.
Suscríbete desde el link de mi perfil