Forem: Josa Vicente

Que nos hace crecer? Coaching vs Mentorship vs Sponsorship

Josa Vicente — Mon, 17 Apr 2023 22:00:00 +0000

Creo que no hay duda, y que si lees este blog estarás de acuerdo, la forma natural de progresar en nuestras carreras no depende únicamente
de nosotros. Obviamente el rol protagonista lo tenemos nosotros, pero lo que marca la diferencia en un momento dado son las relaciones. No estoy
hablando de relaciones por interés, sino de relaciones genuinas.

Todos crecemos con ayuda, todos podemos pensar en una persona o varias que nos han ayudado en nuestras carreras. Pueden ser etapas largas o
simplemente pequeños momentos en los que algún compañero nos aporto una pieza de su experiencia para saber lidiar con un problema.

El objetivo de este post es intentar hacer más relevante, más intencionada y eficaz la forma en la que pedimos ayuda a personas con más experiencia
y como ofrecérsela a las personas de nuestros equipos.

Sponsors, Mentors, and Coaches

Podemos ayudar a nuestros equipos de distintas formas. En función de lo directa o indirecta que sea nuestra forma de actuar. En el ámbito profesional podemos
separar en tres tipos de relaciones:

🗣️ Coaching

La más indirecta de todas, cuando hacemos coaching lo que estamos tratando de generar es la respuesta en la propia persona. No se trata de dar la respuesta, sino
de provocar de distintas formas la propia respuesta en el razonnamiento de la persona que queremos ayudar, mediante preguntas, haciendo challenge o animando a dedicar más
tiempo a la búsqueda o aprendizaje. De nada sirve proporcionar la respuesta directamente, es más, puede que ni la sepamos,
nuestro papel no es saberlo todo y dar la respuestra a nuestro equipo, sino darles las herramientas para encontrar la solución por ellos mismos, generando así
un aprendizaje y desarrollando una experiencia que de otra forma no sería posible.

El coaching se da en las etapas iniciales de un problema/situación, cuando la persona no tiene ni idea de por donde avanzar, se trata de ayudar con el "que" y no con el "como".

📘 Mentoring

En el caso del mentoring, la relación es más directa. En este caso, el mentor es alguien que:

Tiene una expertise técnica que favorece la ayuda a la persona y/o puede darle los recuros y conocimientos necesarios para solucionar un problema.
Es alguien que tiene una experiencia en la empresa o en el sector que puede ayudar a la persona a entender mejor el contexto en el que se mueve.
Ha pasado por la misma situación y por tanto puede dar una guía de como afrontarla.

En este caso, es la siguiente etapa, una vez ya sabes el que, el mentoring ayudará al mentee con el cómo.

🏅 Sponsorship

El sponsorship es la relación más directa de todas. En este caso, el sponsor es alguien que realiza acciones reales para ayudar a la persona a avanzar en su carrera.
Mientras un mentor da consejos, un sponsor te empodera y te ofrece oportunidades reales para crecer. Estas oportunidades pueden ser desde aportar su opinión acerca de una posible promoción,
dar oportunidades en proyectos de mayor visibilidad, ayudarte presentándote personas que pueden crear impacto en tu carrera e incluso ofercerte un nuevo trabajo.

💭 Ok, pero como aplico estos tipos de relaciones?

Tanto si estás en un lado o en el otro, no a todos ni en todo momento nos sirve una de estas figuras. Es posible que por el momento vital/personal en el que te encuentres, no estés preparado
para ser sponsorizado, o tu no puedas sponsorizar a otra persona porque tu rol no te permite esa clase de impacto. Un perfil junior necesitará inicialmente más un coach y una vez es hábil con el "que",
entonces necesitará la figura del mentor. Como en casi todo, la palabra clave es depende.

La mejor forma de hacerlo, es una mezcla de todos ellos. Como Engineer Manager, podremos ser parte o tener el papel de alguno o de varios de estos approaches, pero:

Es imposible serlo de todo el equipo
No siempre estás en la posición o rol adecuado, pero de ser así, tu papel será ayudar a encontrar para esa persona su siguiente next step.

Por ejemplo, cuando se plantea un problema en el que mis skills coincide con las de la persona, actúo como mentor, sugiriendo formas prácticas de avanzar. Cuando no es así, sin embargo, doy un paso atrás y actúo como coach:
les hago reflexionar sobre las cuestiones de fondo, apoyo su forma de razonar y trato de ayudar a encontrar la mejor solución posible.
Mi forma de actuar es ligeramente distinta en el caso de ser un perfil junior. En estos casos, creo que la mejor forma de aprender es pelearse con los problemas y por tanto, en lugar de darles la solución, les planteo las preguntas
que creo adecuadas para hacerles challenge y que saquen su propia solución. Quizá en la primera iteración no sea la mejor, pero cada iteración proporciona posibilidades de aprendizaje distintas.

El papel que se me antoja más complejo es el de sponsor, si bien podemos sponsorizar a distintas escalas, está claro que cuanta más influencia tengas más vas a poder impactar en la carrera de esa persona.

En mi opinión el coaching requiere mucho más esfuerzo, es más duro. Tendemos a mentorizar en su lugar porque el coaching nos exige más, nos exige ser más reflexivos y más pacientes. De todas maneras es la fórmula que más me gusta,
creo que por un lado, lo que te sirve a ti no le sirve a los demás y en un mundo que cambia con tanta rápidez, mentorizar en base a tu experiencia pasada me parece que parte de una base ya obsoleta. Además le quita gran parte
del ownership a la persona que lo recibe, pues no le empodera tanto una vez lo soluciona. Por otro lado, el coaching le permite desarrollar su propia experiencia, lo que le permitirá afrontar problemas similares en el futuro.

🏈 Ahora, como hacerlo en tu equipo?

Bueno, en teoría, en un equipo la gente se ayuda constantemente, o eso debería. Si no es así, este no es el artículo que debes leer. Hay algunos escenarios típicos que pueden facilitar estos tipos de relaciones:

Onboardings

El primer día de un nuevo miembro del equipo es un momento clave para establecer una relación de mentoría. En este caso, el mentor es el que tiene más experiencia en la empresa y el mentee es el nuevo miembro del equipo.

Training a juniors

En este caso, es positivo tanto para el mentor como el mentorizado. El junior recibe ayuda de un perfil experimentado del que aprender y el mentor mejora sus capacidades de comunicación y perfecciona su conocimiento.
La mejor forma de interiorizar conocimiento es compartirlo con los demás. Depende en que lado estés:

Como Engineer Manager: Facilito el crecimiento de los perfiles juniors? Obtienen suficiente mentoría?
Como junior: pide a un compañero senior que sea tu mentor. Pídele consejo de forma recurrente.

La relación con tu manager

Como engineer manager puedes ejercer los distintos papeles:

Como sponsor, ayudas a los miembros de tu equipo a obtener reconocimiento y oportunidades. Por ejemplo, darle la oportunidad de dirigir proyectos con cierta visibilidad o importancia, dar charlas al equipo u otros equipos. En este punto debemos poner especial atención a los sesgos. Está demostrado que mujeres y minorías tienden a ser sobre-mentorizados y infra-sponsorizados.
Como mentor: debes ser más directo y ofrecer consejos de como mejorar las habilidades de una persona. Debes balancearlo bien, ya que un exceso puede tender a quitar ownership del equipo. Es un típico error de managers primerizos o que les cuesta dejar su rol de IC (individual contributor)
Como coach: trabajas para averiguar cuáles son sus objetivos, qué le hace feliz y qué dirección quiere dar a su carrera. Aquí tenemos el error contrario, si nos pasamos de dejar a la persona sin cierta dirección, podemos provocar frustración y desmotivación al dejar que choquen demasiado a menudo con los problemas.

🌎 Y si no puedes hacerlo en tu trabajo?

Si no puedes desarrollar estas relaciones en tu puesto de trabajo, ya sea dándolas o recibiéndolas. Otras opciones pueden ser:

Tu red, si tienes una red de contactos, puedes buscar a alguien que pueda ser tu mentor. Si no tienes una red, puedes empezar a construirla.
Comunidades
Conferencias
Meetups
Coaching profesional

🗒️ Conclusión

Tanto en un sentido u otro, las distintas relaciones tienen aportes en tu carrera que merecen la pena explotar. Como persona que durante mucho tiempo no tuvo ningún tipo de estas relaciones, tener que construirlas es complejo y agotador.
Por este motivo, en mi caso, me esfuerzo por construirlas tanto para mi equipo como para mi. Creo que es una inversión que merece la pena y que aporta mucho valor tanto para el equipo como para uno mismo.

Principios SOLID VI: Principio de inversión de dependencias

Josa Vicente — Sun, 16 Apr 2023 22:00:00 +0000

El principio de inversión de dependencias indica que las clases de un sistema deben depender de las abstracciones/interfaces y no de las implementaciones concretas. Esto significa que las clases no deben depender directamente de clases específicas, sino de interfaces o clases abstractas. Esto lo haremos inyectando dependencias en el constructor de la clase, pero estas dependencias serán interfaces o clases abstractas, no clases finales.

Un ejemplo de violación del principio de inversión de dependencias en un programa inspirado en Pokemon podría ser el siguiente. Tenemos una clase PokemonTrainer que se encarga de entrenar a un Pokemon específico y una clase Charizard que representa a un Pokemon de tipo fuego.


class PokemonTrainer {
    fun train(pokemon: Charizard) {
    }
}

class Charizard {
}

En este ejemplo, la clase PokemonTrainer tiene una dependencia directa con la clase Charizard y solo puede entrenar a ese tipo de Pokemon específico, lo cual viola el principio de inversión de dependencias ya que la clase PokemonTrainer depende directamente de la implementación concreta de una clase Charizard y no de una abstracción o interfaz que represente cualquier Pokemon.

Un ejemplo correcto sería tener una interfaz Pokemon y modificar la clase PokemonTrainer para depender de esta interfaz:

interface Pokemon {
    fun train()
}

class Charizard : Pokemon {
    override fun train() {

    }
}

class PokemonTrainer {
    fun train(pokemon: Pokemon) {
        pokemon.train()
    }
}

De esta manera, la clase PokemonTrainer depende de una abstracción, la interfaz Pokemon, en lugar de una implementación concreta. Esto permite que se puedan entrenar diferentes tipos de Pokemon en lugar de solo uno específico. Además, si se desea añadir otro tipo de Pokemon, solo se requiere crear una nueva clase que implemente la interfaz Pokemon y no tener que modificar la clase PokemonTrainer.

Este princpio es una de los más importantes. Cuando escriba sobre arquitectura hexagonal, veremos que se basa en gran medida en el uso de esta inyección de dependencias con el objetivo de facilitar la modificación y la sustitución de implementaciones en entornos cambiantes y que escalan rápidamente tras demostrar una hipótesis.

Además este principio facilita la testabilidad de las clases porque permite desacoplar las dependencias de las clases. En lugar de crear las dependencias dentro de la clase, las dependencias se pasan a la clase a través de su constructor o métodos de configuración. Esto significa que las dependencias pueden ser fácilmente reemplazadas por sus equivalentes de prueba, lo que permite probar la clase de forma aislada. Veámoslo con un ejemplo:


interface PokemonRepository {
    fun getPokemon(pokemonId: Int): Pokemon
}

class PokemonService(private val repository: PokemonRepository) {
    fun getPokemonName(pokemonId: Int): String {
        val pokemon = repository.getPokemon(pokemonId)
        return pokemon.name
    }
}

En este ejemplo, PokemonService tiene una dependencia en PokemonRepository. En lugar de crear una instancia de PokemonRepository dentro de PokemonService, se pasa una instancia de PokemonRepository al constructor de PokemonService. Así podremos proporcionar una implementación de prueba o mock de PokemonRepository cuando creamos una instancia de PokemonService para probarlo, lo que nos permite aislar la prueba de PokemonService de su dependencia en PokemonRepository.

Un ejemplo de código para dicho test:


class TestPokemonRepository : PokemonRepository {
    override fun getPokemon(pokemonId: Int): Pokemon {
        return Pokemon(pokemonId, "Pikachu")
    }
}

class PokemonServiceTest {
    @Test
    fun `test getPokemonName`() {
        val repository = TestPokemonRepository()
        val service = PokemonService(repository)
        val pokemonName = service.getPokemonName(25)
        assertEquals("Pikachu", pokemonName)
    }
}

Creamos un mock llamado TestPokemonRepository que implementa PokemonRepository. TestPokemonRepository devuelve siempre un objeto Pokemon de prueba con el nombre "Pikachu" independientemente del ID del Pokemon que se le pase.

En la clase de prueba PokemonServiceTest, creamos una instancia de TestPokemonRepository y la pasamos al constructor de PokemonService. Luego llamamos al método getPokemonName con un ID de Pokemon específico y verificamos que el nombre devuelto sea el esperado.

Así aislamos la prueba de PokemonService de su dependencia con PokemonRepository.

Y hasta aquí la serie de artículos sobre los principios SOLID.

Principios SOLID V: Principio de segregación de interfaces

Josa Vicente — Thu, 13 Apr 2023 22:00:00 +0000

El principio de segregación de interfaces establece que una clase no debe ser obligada a implementar métodos que no utilizará. En otras palabras, una clase debe implementar solo los métodos necesarios para su comportamiento específico.

Traduciendolo al mundo real, debemos diseñar las interfaces pensando en quien las usará, sus clientes, no en implementaciones concretas que pudieran tener.

Veámoslo con un ejemplo, como hasta ahora, seguimos con Pokemons.

Tenemos una interfaz PokemonActions que define métodos para realizar acciones comunes a todos los Pokemon, como atacar, defenderse, etc. Además, se tiene una clase FlyingPokemon que representa a un Pokemon volador y otra clase ElectricPokemon que representa a un Pokemon eléctrico.


interface PokemonActions {
    fun attack()
    fun defend()
    fun fly()
    fun electricShock()
}

class FlyingPokemon : PokemonActions {
    override fun attack() {
        // codigo ataque
    }
    override fun defend() {
        // codigo defensa
    }
    override fun fly() {
        // codigo vuelo
    }
    override fun electricShock() {
        // codigo imposible de ejecutar
    }
}

class ElectricPokemon : PokemonActions {
    override fun attack() {
        // codigo ataque
    }
    override fun defend() {
        // codigo defensa
    }
    override fun fly() {
        // codigo imposible de ejecutar
    }
    override fun electricShock() {
        // codigo electricShock
    }
}

En este ejemplo, la interfaz PokemonActions obliga a las clases FlyingPokemon y ElectricPokemon a implementar el método fly(), a pesar de que solo es relevante para los Pokemon voladores, y electricShock(), solo relevante para los Pokemon eléctricos. Por lo tanto, se viola el principio de segregación de interfaces ya que se obliga a las clases a implementar métodos que no utilizarán.

La forma correcta de implementarlo siguiendo el principio de segregación de interfaces:

interface FlyingPokemonActions {
    fun attack()
    fun defend()
    fun fly()
}

interface ElectricPokemonActions {
    fun attack()
    fun defend()
    fun electricShock()
}

class FlyingPokemon : FlyingPokemonActions {
    override fun attack() {
        // codigo ataque
    }
    override fun defend() {
        // codigo defensa
    }
    override fun fly() {
        // codigo vuelo
    }
}

class ElectricPokemon : ElectricPokemonActions {
    override fun attack() {
        // codigo ataque
    }
    override fun defend() {
        // codigo defensa
    }

De esta manera, todo está en su sitio, ninguna clase tiene métodos inservibles y el código es claro y más descriptivo. El objetivo es tener alta cohesión y bajo acoplamiento.

Principios SOLID IV: Principio de sustitución de Liskov

Josa Vicente — Tue, 11 Apr 2023 22:00:00 +0000

LSP o Liskov Substitution Principle es una definición particular de una relación de subtipificación, llamada tipificación (fuerte) del comportamiento, que fue introducido por Barbara Liskov en 1987 en una conferencia y reformulado junto a Jeannette Wing en 1994:

Sea ϕ(x) una propiedad comprobable acerca de los objetos x de tipo T. Entonces ϕ(y) debe ser verdad para los objetos y del tipo S, donde S es un subtipo de T.

Por la forma en la que tiene siempre de explicarse este principio y por su nombre, parece más complicado de lo que realmente es. Una forma más clara de definirlo es:

Si una clase B es una subclase de una clase A, entonces un objeto de la clase B debería poder ser utilizado en cualquier lugar donde se espera un objeto de la clase A, sin causar ningún comportamiento inesperado. En otras palabras, una subclase debe ser capaz de sustituir a su superclase sin causar problemas.

Si os ha explotado la cabeza, ok, me pasó igual 🤯

Con un ejemplo lo veremos muy fácil. De nuevo Pokemon.

Tenemos una clase Pokemon que representa a un Pokemon en general, y varias subclases que representan a los diferentes tipos de Pokemon (como FirePokemon, WaterPokemon, etc.).

Si en la clase FirePokemon se incluye un método burnOpponent() que reduce la salud del oponente en una cantidad específica de puntos de salud, sin embargo la clase waterPokemon no incluye un método equivalente para reducir la salud del oponente. Entonces si tenemos la función battle(p1: Pokemon, p2: Pokemon) para simular una combate entre pokemon, vemos que no funcionaría correctamente si se utilizara un WaterPokemon en lugar de un FirePokemon.


class Pokemon {
    var name: String = ""
    var healthPoints: Int = 0
}

class FirePokemon: Pokemon() {
    var firePower: Int = 0
    fun burnOpponent(p: Pokemon) {
        p.healthPoints -= firePower
    }
}

class WaterPokemon: Pokemon() {
    var waterPower: Int = 0
}

fun battle(p1: Pokemon, p2: Pokemon) {
    while (p1.healthPoints > 0 && p2.healthPoints > 0) {
        if(p1 is FirePokemon) p1.burnOpponent(p2)
        // combate aqui
    }
}

val charmander = FirePokemon()
val squirtle = WaterPokemon()

battle(charmander, squirtle)

En este ejemplo, un WaterPokemon no puede ser utilizado en lugar de un FirePokemon en el método battle ya que no tiene una forma de reducir la salud del oponente, lo que causaria un comportamiento inesperado. El principio de sustitución de Liskov se viola ya que un objeto de la subclase no puede ser utilizado en lugar de un objeto de la superclase sin causar problemas.

La forma correcta de implementarlo siguiendo el principio de Liskov sería:

class Pokemon {
    var name: String = ""
    var healthPoints: Int = 0
}

class FirePokemon: Pokemon() {
    var firePower: Int = 0
    fun burnOpponent() {/*...*/}
}

class WaterPokemon: Pokemon() {
    var waterPower: Int = Int = 0
    fun drenchOpponent() {/*...*/}
}

fun battle(p1: Pokemon, p2: Pokemon) {
    while (p1.healthPoints > 0 && p2.healthPoints > 0) {
        // combate aqui
    }
}

val charmander = FirePokemon()
val squirtle = WaterPokemon()

battle(charmander, squirtle)

De esta manera, se asegura que los objetos de una subclase se comportan de forma esperada, siempre que se utilicen en lugares donde se espera un objeto de su superclase.

Toda subclase debe ser compatible con todos los métodos y propiedades de la superclase, y no solo aquellos que se utilizan en el contexto actual, ya que cualquier cambio en la superclase podría afectar a la subclase.

El objetivo principal de este principio es mantener correctitud funcional para poder aplicar OCP.

Principios SOLID III: Abierto a extensión y cerrado a modificación

Josa Vicente — Sun, 09 Apr 2023 22:00:00 +0000

El software debería estar abierto a extensión y cerrado a modificación. Para ello, evitemos depende de implementaciones específicas. Es más sencillo con un ejemplo.

Volvamos sobre el ejemplo del post anterior inspirado en Pokemon.
Vamos a añadir a la clase base el nombre, nivel y hp del pokemon en cuestión. Ahora añadimos clases hijas para los tipos de pokemon, por ejemplo fuego y agua.

La clase base tiene una método attack, recibe un pokemon y le reduce su hp basado en el nivel de ataque del pokemon.

Al principio, este diseño funciona bien. Sin embargo, a medida que añades más características al juego, te das cuenta de que necesitas añadir diferentes tipos de ataque, como fuego y agua, que son fuertes o débiles contra ciertos tipos de Pokemon.

Para implementar esto, podrías añadir un nuevo atributo llamado attackType a la clase Pokemon y modificar el método de ataque para tener en cuenta el tipo de ataque del Pokemon atacante y el tipo del Pokemon defensor.

Aquí el error, esto violaría el Principio Abierto-Cerrado, que como describía al inicio, establece que una clase debe estar abierta a extensiones, pero cerrada a modificaciones. Deberías ser capaz de añadir nuevas funcionalidades a una clase sin cambiar su código existente.


// Clase Base
open class Pokemon(val name: String, var level: Int, var hp: Int) {
    // Método de ataque
    fun attack(target: Pokemon) {
        when (this) {
            is FirePokemon -> {
                if (target is WaterPokemon) {
                    target.hp -= 2 * level
                } else {
                    target.hp -= level
                }
            }
            is WaterPokemon -> {
                if (target is FirePokemon) {
                    target.hp -= 2 * level
                } else {
                    target.hp -= level
                }
            }
        }
    }
}

// Subclases para tipos de pokemon específicos
class FirePokemon(name: String, level: Int, hp: Int) : Pokemon(name, level, hp)
class WaterPokemon(name: String, level: Int, hp: Int) : Pokemon(name, level, hp)

En este ejemplo, la clase Pokemon no está abierta a extensiones porque no puedes añadir nuevos tipos de ataque a un Pokemon sin modificar el método de attack. Para añadir un nuevo tipo de ataque, tendrías que modificar el método para tener en cuenta el nuevo tipo de ataque, lo que provocaría cambiar todas las llamadas a dicho métrodo y obviamente viola OCR.

En su lugar, podrías seguir OCR creando una nueva clase Ataque que tenga un atributo attackType y un método calculateDamage que reciba un objeto Pokemon y devuelva la cantidad de daño a infligir. Luego puedes extender la clase Ataque para crear tipos de ataque específicos como AtaqueFuego y AtaqueAgua.

La clase Pokemon puede entonces tener una lista de objetos Ataque y un nuevo método use_attack que selecciona un ataque de la lista y lo usa para atacar a otro Pokemon. De esta manera, puedes añadir nuevos tipos de ataque al juego sin modificar la clase Pokemon existente. Para ello usaríamos un método learnAttack, que como su nombre indica simplemente añadiría ataques a la lista de dicho pokemon.


open class Pokemon(val name: String, var level: Int, var hp: Int) {

    private val attacks = mutableListOf<Attack>()

    fun useAttack(attack: Attack, target: Pokemon) {
        val damage = attack.calculateDamage(target)
        target.hp -= damage
    }

    fun learnAttack(attack: Attack) {
        attacks.add(attack)
    }
}

// Clase base para ataques
open class Attack(val name: String, val attackType: AttackType) {
    open fun calculateDamage(target: Pokemon): Int {
        return when (attackType) {
            AttackType.FIRE -> {
                if (target is WaterPokemon) {
                    2 * level
                } else {
                    level
                }
            }
            AttackType.WATER -> {
                if (target is FirePokemon) {
                    2 * level
                } else {
                    level
                }
            }
        }
    }
}

class FireAttack(name: String) : Attack(name, AttackType.FIRE)
class WaterAttack(name: String) : Attack(name, AttackType.WATER)

class FirePokemon(name: String, level: Int, hp: Int) : Pokemon(name, level, hp)
class WaterPokemon(name: String, level: Int, hp: Int) : Pokemon(name, level, hp)

enum class AttackType {
    FIRE, WATER
}

En este ejemplo, la clase Pokemon está abierta a extensiones (puedes añadir nuevos ataques a un Pokemon usando el método learnAttack), pero cerrada a modificaciones (no necesitas modificar la clase Pokemon para añadir nuevos tipos de ataque). En su lugar, puedes crear nuevos tipos de ataque extendiendo la clase Ataque y sobreescribiendo el método calculateDamage.

Principios SOLID II: Principio de responsabilidad única

Josa Vicente — Wed, 05 Apr 2023 22:00:00 +0000

Seguimos con SOLID, en esta ocasión la S que corresponde al principio de responsabilidad única. Es posiblemente el más sencillo de identificar y también uno de los más sencillos de violar. Viene a decirnos que cada clase debe tener una única responsabilidad y que debe estar encapsulada en dicha clase. Por tanto cada clase debe tener un propósito específico que debemos identificar y no ser como una navaja suiza multifunción. Aquí el naming es importante para ser específicos.

Me gusta especialmente porque hace el código fácilmente legible y entendible. Cualquiera que venga a revisar un código que cumple SRP, será capaz de identificar y entender rápidamente su objetivo.

Una clase = un concepto = una responsabilidad

Veamos un ejemplo en Kotlin, tenemos esta clase inspirada en Pokemon:

class Pokemon {
    val name: String
    val type: String
    val level: Int

    fun attack() {
    // realiza un ataque
    }

    fun evolve() {
    // evoluciona el Pokemon
    }

    fun calculateExperience() {
    // calcula la experiencia del Pokemon
    }
}

En este ejemplo, la clase Pokemon tiene tres responsabilidades: atacar, evolucionar y calcular la experiencia. Por lo tanto estamos violando SRP. Cada tarea debería realizarse por una clase distinta. Lo correcto sería:

class Pokemon {
    val name: String
    val type: String
    val level: Int

    fun attack() {
    // realiza un ataque
    }
}

class Evolution {
    fun evolve(pokemon: Pokemon) {
    // evoluciona el Pokemon
    }
}

class ExperienceCalculator {
    fun calculateExperience(pokemon: Pokemon) {
    // calcula la experiencia del Pokemon
    }
}

Podría haber hecho el típico ejemplo de la impresión o la BBDD, pero ilustrarlo con este ejemplo me ha parecido más divertido. Quizá semánticamente o el significado de negocio no sea tan directo, pero es mi blog, es mi ejemplo.

Aplicar SRP implica ser muy preciso con los nombres. Esto es especialmente importante, ya que según el tamaño del proyecto. la granularidad puede ser elevada y dificultar la navegación en el mismo. Cuanto más descriptiva y clara sea una clase por su nombre, más fácil nos será ubicarnos dentro del código.

La principal pega que se le achaca a SRP es que aunque facilita el mantenimiento del código, perjudica, sobretodo en un proyecto grande, por la complejidad de la estructura de clases y el número de las mismas. En mi opinión, las ventajas a medio largo plazo compensan esto. Por muy grande que sea la base de código, será mucho más complejo hacer cambios si hay que tocar en muchas clases por una mala arquitectura. Sin embargo, quizá por volumen pueda llevar más tiempo entender la estructura, pero una vez entendida, el cambio será en un solo lugar.

A continuación las principales ventajas que aporta SRP:

Facilita el mantenimiento y la actualización del código: Al tener cada clase una única responsabilidad, es más fácil localizar y modificar el código si es necesario.
Mejora la legibilidad del código: Al tener cada clase un propósito específico, es más fácil entender su función y cómo se relaciona con el resto del código.
Facilita la reutilización del código: Al tener cada clase una responsabilidad específica, es más fácil utilizar esa clase en diferentes partes del proyecto sin tener que modificarla.

Algunos inconvenientes:

Puede aumentar la complejidad del proyecto: Al tener que dividir las responsabilidades en varias clases diferentes, puede resultar en una estructura más compleja y difícil de entender.
Puede requerir más tiempo de desarrollo: Al tener que crear más clases y establecer relaciones entre ellas, puede requerir más tiempo de desarrollo.

Como en todo en desarrollo, esto son principios, no leyes, obviamente depende del proyecto/product y del equipo establecer cuando tiene sentido hacer un trade off.

Principios SOLID I: Primero, no seas STUPID

Josa Vicente — Wed, 05 Apr 2023 08:00:00 +0000

Esta es la primera de una serie de entradas sobre los principios SOLID. Mi idea es hacer una entrada por principio
pero quería comenzar precisamente con sus antagonistas. La mayoría del tiempo trabajamos con código legado. En un
mundo ideal, lo haríamos todo desacoplado, mantenible y testable. Pero tristemente en muchos proyectos,
te encuentras el gran marrón del código legado.

He tenido que "remontar" ya más de tres veces grandes bases de código legado. En todas esas ocasiones, cuando tienes
que rehacer o refactorizar algo, los grandes aliados son precisamente todo lo contrario a SOLID, conocerlos
bien y por tanto detectarlos rápidamente.

Es por eso, que si he de empezar a hablar de los principios SOLID, casi mejor empezar por precisamente por lo
contrario, ya que con toda probabilidad, en muchos proyectos te encuentres precisamente con lo contrario. Empecemos.

Antes un pequeño disclaimer. Los principios SOLID así como los patrones de diseño, son opciones que tenemos para solucionar
problemas. En software casi todo es un trade off, lo que ganas por un lado lo puedes perder por otro. Por tanto,
nada es inamovible y siempre debemos tomar las decisiones que mejor encajen con nuestra situación, es más,
esas decisiones cambiarán con el tiempo casi con total probabilidad.

STUPID

1. Singleton

Patrón de diseño singleton, es decir, restringir la instanciación de una clase a una única instancia. El problema en si no
es el patrón, el problema es su mal uso.

Ejemplo en Kotlin:

object Cache{
    fun clearCache(){
        ...
    }
    fun saveOnCache(){
        ...
    }
}

Ejemplos típicos serían el de caché o BBDD. Tendriamos nuestra clase Cache, con sus métodos estáticos que estarían siendo llamados
por todas partes en nuestro código. Teniendo el singleton dejamos de inyectar dependencias en nuestras clases lo que:

Te fastidia el testing al depender de un estado global
Si nuestras clases dependen del objeto singleton, ocultan sus dependencias.
Todo nuestro sistema se encuentra acoplado al objeto/s singleton.

Casi siempre puedes optar por otra opción antes que el Singleton.

2. Tight Coupling - Código fuertemente acoplado

Relacionado con el anterior, consecuencia de utilizar singleton. En el ejemplo anterior, imagínate que queremos modificar la cabecera
de alguno de los métodos estáticos. Tendríamos que modificar todas y cada una de las llamadas que hagamos a estos en todo nuestro código. Claramente estamos
acoplados a como sea la implementación de la clase.

3. Untestability - Código no testable

En muchos de los proyectos los tests brillan por su ausencia, sobretodo en el mundo de la consultoría, donde se considera que los tests no son parte del desarrollo
y por tanto no se contempla dedicarles tiempo. Sin embargo, si pensamos en entornos con CD/CI por bandera, por poner un ejemplo claro, son imprescindibles para
garantizar que no se rompe el ciclo.

Tu código debe ser fácilmente testable. Es más, si tu código es difícil de testar, claramente tienes un problema. Lo que esa dificultad para testar te dice es que tu código
no es mantenible y probablemente esté sumamente acoplado. Unos buenos tests te permitirán refactorizar sin peligro.

4. Premature Optimization

Básicamente, no te flipes. Los desarrolladores tendemos a fliparnos y complicarnos la vida. Nos adelantamos a lo que pueda pasar y muchas veces, eso, nunca pasa.
Una optimización prematura lleva a costes innecesarios tanto en tiempo como económicos. Primero, valida tu hipótesis, luego ya montarás la BBDD más actual o la UI
con el framework de moda.

5. Indescriptive naming

Poco que decir, básicamente pon nombres que tu yo del futuro sea capaz de entender de un vistazo para que sirven. Por favor, no sigas esas tendencias de nombres crípticos
o varibales de una sola letra. Eso es para señoros con riñonera que huelen fuerte.

6. Duplication

No dupliques código. Si duplicas código te vas a tener que patear toda la base de código para corregir cualquier pequeño error. A estas alturas diría que es obvio, pero el ser humano
es sorprendende para mal casi siempre.

Radical Candor III: Escucha más, habla menos.

Josa Vicente — Tue, 04 Apr 2023 08:00:00 +0000

Te estarás preguntando porque la imagen de cabecera es la de Jony Ive, el que fue el jefe de diseño de Apple durante 27 años, cuando el post es sobre el contenido de Radical Candor.
Jony en una ocasión dijo:

Give the quiet ones a voice

Es decir, da voz a los silenciosos. Esta frase resume a la perfección la idea del post y es el punto de partida de cara al último post sobre Radical Candor, la rueda de Get Stuff Done.
Para que las cosas pasen, hay que escuchar. Hay distintas formas de escuchar y de fomentar esa cultura de escucha.

Quiet listening

El hecho de estar callado y escuchar, acaba provocando en el interlocutor la necesidad de llenar ese silencio. Esto lleva a obtener más información de la que se podría obtener con una pregunta directa.
Es una forma de escuchar que se basa en la empatía y en la capacidad de ponerse en el lugar del otro. No solo obtienes más información y por tanto conoces mejor a la persona y como ayudarla.
También obtienes más feedback, cosas que igual no dirían. También fomentas que la otra persona comparta ideas que si fuera interrumpida no aportaría.

Por otro lado, tiene algunas contras, como que la gente tiende usar tu nombre, para acabar yendo por el camino que ellos creen mejor, sin escuchar al resto y justificando que es lo
que tu piensas. Tu silencio, acaba dejando que se salgan con la suya. Otra contra es que los silencios suelen provocar cierto malestar en algunas personas. En lugar de percibirse como una
conversación sincera, se percibe como una conversación tensa o una trampa.

Si tu forma de escucha es esta, tienes que tomar medidas para mitigar las contras. Especialmente tranquilizar a los que se sienten incómodos por tu estilo.
No seas inescrutable. Para que los demás digan lo que piensan, a veces tienes que decir tú también lo que piensas.

Un ejemplo de este tipo de líder es Tim Cook, el actual CEO de Apple.

Loud listening

La forma opuesta, esta forma de escucha se basa establecer un punto de vista fuerte que provoque una reacción en los demás y les haga hablar.
Se trata de retar al equipo a aportar sus ideas y sobretodo rebatir las expuestas. Obviamente, esto solo puede funcionar con personas que tengan mucha confianza. Esto normalmente no
ocurre, en un equipo donde hay muchos tipos de perfiles, personas más seguras de si mismas, introvertidas, personas que acaban de incorporarse, etc. Todas ellas probablemente tengan un punto
de vista diferente y/o mejor a un problema pero no se atreverán a hablar.

Si este es el tipo de escucha con la que te identificas, tienes que generar un entorno de confianza y promover la participación de todos. Sea cual sea el tipo de perfil. Si cualquiera desafía las opiniones
del jefe y es escuchado y valorado, aquellos con menos confianza acabarán aportando también. Por supuesto, debes ser capaz de asimilar las críticas porque este tipo de escucha busca el debate
y precisamente lo que buscas es que todo el equipo se sienta suficientemente empoderado para aportar sus ideas, no importa el nivel de expertise o el cargo que tenga. Aquí todos son iguales, tú incluído.

Un ejemplo de este tipo de líder es Steve Jobs, el fundador de Apple. Este comentario sobre Steve Jobs lo resume muy bien:

He’s a lion. If he roars at you, you’d better roar back just as loudly — but only if you really are a lion, too. Otherwise, he’ll eat you for lunch.

Crea una cultura de escucha

Hasta ahora hemos hablado de como escuchar desde tu posición de liderazgo. Pero aquí no acaba, hay que promover la escucha entre las personas del equipo.
Se trata de establecer un sistema en el que se puedan aportar ideas y expresar quejas, pero que también permita abordarlas y resolverlas. No tienes porque ser tu, quien las lleve a cabo o las gestione.

Este feedback debe ser contestado, el tiempo es limitado y por tanto, has de dejar claro que no todo se puede abordar.
Pero debes asegurarte de abordar aquello que aporte un mayor impacto para todos. Aquellas que no se puedan abordar deben ser comunicadas
y en la medida de lo posible bien clarificados los porques.

Cuando esas ideas se lleven a cabo y generen un impacto, no solo debes reconocer la aportación, es muy valioso que muestres a esa persona y al
equipo el impacto real que ha tenido. Esto fomentará que se sigan aportando ideas y que se siga escuchando las ideas de los demás, creando una cultura de escucha efectiva.

Otro punto importante es saber gestionar las reuniones de forma adecuada, si siempre hablan los mismos, hay un problema, todos los miembros del equipo deben tener
espacio y se debe incentivar la participación. Tu trabajo es, como dice Jony Ive, dar vos a los silenciosos.

Conclusión

Una cultura que promueva que todo el mundo es escuchado y tiene las mismas oportunidades de aportar y generar impacta propicia las bases de un entorno
de trabajo saludable y productivo, en el que se materializan resultados. Es un trabajo de todos, no solo tuyo como engineer manager. Pero si tú no fomentas la escucha, no se puede esperar que el resto lo haga.

Radical Candor II: Rockstars vs. Superstars

Josa Vicente — Sun, 02 Apr 2023 22:00:00 +0000

Trabajamos en un sector con una alta demanda de talento. Sabemos que si no damos a las personas del equipo lo que necesitan según el momento vital en el que se encuentran,
lo tendrán muy fácil para encontrar otro lugar donde desarrollar su talento y que encaje con sus necesidades. Debemos ser conscientes de que la gente no se queda en
un lugar solo porque le gusta el trabajo, sino porque encaja con sus necesidades personales. Estas necesiades pueden ser económicas, de crecimiento, autonomía, etc.

En el libro Radical Candor, en lugar de pensar en la personas según su performance, se habla de crecimiento. Utilizando una tabla de crecimiento, se puede ver como cada persona
encaja en el equipo según su momentum de crecimiento. Un equipo debe estar balanceado, sus perfiles deben ser un engranaje perfecto, no únicamente a nivel técnico, sino también
a nivel personal. Si no hay balance, el equipo no funcionará. Y no solo eso, las personas acabaran frustrándose y buscando otro lugar que les encaje mejor.

Los miembros de un equipo se pueden encontrar en distintas fases de crecimiento, a veces están en modo crecimiento, otras veces busacna estabilidad y en algunas ocasiones ambas cosas.
Pero los dos perfiles que van a mantener el equipo unido y hacerlo funcionar como una maquinaria perfecta son:

Rockstars

Estos perfiles son sólidos, tienen unas skills técnicas potentes, han encontrado su sitio y están en total harmonía con su rol actual.
No buscan el siguiente step en su carrera. Estan cómodos como están y en ese momento de su carrera no quieren más. Es importante que los mantengamos en el equipo,
ya que son los que van a generar crecimiento en el equipo compartiendo el suyo y mentorizando. El error
más repetido con este tipo de perfil es promociopnarles a un puesto que no desean y para el que además no están preparados.

Por desgracia en nuestro sector es común recompensar a los mejores desarrolladores con puestos de management o liderazgo para los que no están preparados y además ni siquiera quieren.
Lo he visto muchas veces, lo he vivido como miembro de un equipo, son excelentes técnicos que ni quieren ni les gusta gestionar y liderar equipos porque eso les aparta de lo que realmente les apasiona, actividades técnicas.
Lo que suele ocurrir:

No ejercen su papel de liderazgo, siguen programando y por tanto su equipo se resiente, provocando una sangría de perfiles que se queman y se van.
Tratan de ejercer ese papel de liderazgo y management, unas veces acertadamente y otras todo lo contrario. Provocando quemar al equipo y que se vayan. Y además acaban abandonando y buscando un puesto que les devuelva la felicidad.

Tu labor como líder en un equipo en el que tengas uno o más rockstars es centrarte en ofrecerles reconocimiento tanto a nivel de equipo como económico. Es muy importante que balancees
los aportes individuales vs colaborar en equipo, tienden a priorizar su propio trabajo sobre el éxito del equipo. Debes fomentar que compartan su conocimiento con el resto del equipo,
que sean mentores y que se involucren en el crecimiento de los demás aportando su conocimiento y experiencia.

Algunos tips:

No los promociones, es lo peor que podrías hacerles. Si no quieren ser managers, no lo hagas. Si lo haces, acabarás perdiendo a un excelente técnico y a un excelente miembro del equipo.
No crees una obsesión por la promoción. No es el fin del mundo. La tendencia que el siguiente paso para un desarrollador experimentado es el management cada vez es menos común.
Buenos bonus y Performance ratings.
Reconocimiento público. El status de gurú es muy importante para ellos.
Respeto. Por su trabajo, sus skills y lo que aportan al equipo.

Superstars

En el otro lado tenemos a los Superstars. Son excelentes pero en modo turbo. Buscan el crecimiento constante, nuevos retos y oportunidades. Además lo que les motiva es
que se les rete. No solo generan un gran trabajo, además ayudan a otros a mejorar. Priorizan el éxito del equipo por encima de sus contribuciones individuales.

Tu labor como líder en un equipo en el que tengas uno o más superstars es centrarte en ofrecerles retos y oportunidades de crecimiento. Son los que verdaderamente impulsan el éxito del equipo
como un todo. Son los que fomentan la comunicación y colaboración en el equipo, lo que lleva a mejores resultados y a un mejor ambiente de trabajo. Crean un sentido de propósito compartido hacia la
misión y visión de la compañía y del equipo.

Tu labor como líder en un equipo con Superstars es ofrecerles retos y oportunidades de crecimiento.

Algunos tips:

Retos
No los frenes, no les pongas límites. Siempre hay más por hacer.
Define un plan de crecimiento para ellos. No lo dejes al azar.
Mentorizalos o asignales un mentor que les guíe en su crecimiento.

Encuentra el balance

El objetivo es encontrar el balance entre estos dos perfiles. Si tienes un equipo con muchos rockstars, el equipo se estancará.
Si tienes un equipo con muchos superstars, el equipo se desintegrará.

Las personas tenemos momentos vitales distintos la que hoy es un rockstar, quizá mañana esté en fase de crecimiento y se convierta en un superstar. Como líder debes estar atento a los cambios
ya que tu rol requiere adaptabilidad. Lo que les has de ofrecer irá cambiando según el momento vital de cada persona.
Por ejemplo, yo mismo he pasado por ambas etapas varias veces, no voy a denominarme ni una cosa ni la otra, pero he pasado por fases en las que quería crecer y otras en las que quería estabilidad.

Conclusión

Como líderes debemos ser flexibles y adaptarnos a las necesidades de cada persona. No podemos asumir que todos queremos lo mismo. Y mucho menos pensar que siempre a lo largo de nuestra carrera
buscamos lo mismo. Tu trabajo es identificar cada perfil, entender que es lo que necesitan y dárselo o encontrar las herramientas para dárselo, generando así una cultura positiva de equipo. Con ello
lograrás que tu equipo sea más productivo, más feliz y más comprometido.

Os dejo la charla de Kim Scott por si la queréis ver:

Radical Candor: framework

Josa Vicente — Sun, 02 Apr 2023 10:55:43 +0000

Radical Candor es un concepto creado por Kim Scott. Yo lo conocí a través de una charla que realizó y que hará un año vi por primera vez. De ahí, me hice con el libro y recientemente me lo he leído. Me ha gustado tanto que no solo lo recomiendo, sino que he decidido hacer varios posts sobre el mismo.

En esta primera entrada voy a hablar sobre el framework en si. El libro se divide en dos partes. En la primera, Kim Scott explica el concepto de Radical Candor, como focalizarse en el crecimiento del equipo y que las cosas se hagan. En la segunda, nos da consejos para aplicar todo lo explicado en la primera parte en tu día a día.

El framework se basa en una disposición en cuadrantes. Algo que debemos tener en cuenta es que este cuadrante no es una forma de etiquetar a las personas, sino que es una brújula o guía para dar y recibir feedback. El objetivo como managers debemos precuparnos por las personas de forma sincera y honesta. Y por otro lado que seamos directos, aunque sea duro, para ayudar a la persona a mejorar.

Estos 4 cuadrantes tienen los siguientes nombres:

Radical Candor

Se trata de demostrar que te importa personalmente, tanto como para dar una opinión sincera y directa para hacer challenge a la persona. Es ser honesto, cercano y directo. Es el tipo de feedback que tiene una utilidad para el que lo recibe e incluso para el que lo da. Es el tipo de feedback que se debe dar en el día a día. Si dejamos pasar la oportunidad, estamos perdiendo una oportunidad de crecimiento para el que lo recibe y para nosotros mismos. Y es que, si no lo hacemos, no estamos siendo honestos con nosotros mismos.

Ruinous Empathy

Es lo que ocurre cundo quieres evitar cualquier sentimiento a corto plazo de alguien, ya sea positivo o negativo, por tanto, no comunicas lo que piensas. Es un feedback no sincero, sin utilidad para quien lo recibe. Si, te estás preocupando por el bienestar de la persona, pero no estás siendo honesto con ella y no la estás desafiando directamente para mejorar. Por tanto, es un feedback que:

Elogios que no son suficientemente específicos para ayudar a la persona a entender lo que ha hecho bien.
Críticas suavizadas, poco claras que no ayudan a la persona a entender lo que ha hecho mal.

Para ejemplificarlo podrías tomar la situación, que a todos nos ha pasado, en la que estamos comiendo con alguien y tras acabar, tiene los dientes manchados con algún trozo de comida. En lugar de avisarle, no dices nada. Lo que provoca que pase toda la tarde con los dientes manchados exponiéndose a que le digan algo.

De esta manera, por no ser directo, no estás dando a la persona la oportunidad de mejorar.

Obnoxious Aggressiveness

Se podría traducir como agresión odiosa, también llamada honestidad brutal. Aquí estás desafiando a la persona, pero no te importa personalmente. Los elogios no parecen sinceros y las críticas son agresivas, no se hacen con amabilidad. Es decir, no se hace con el objetivo de ayudar a la persona a mejorar, sino con el objetivo de hacerle sentir mal. El tipo de personas que actuan de esta manera, usan la culpabilidad que generan en quien recibe el feedback, como motor para la mejora. Suele confundirse con Radical Candor.

Manipulative Insincerity

Aquí ni te preocupas ni desafias a la persona. Puede ser un elogio inespecífico o una crítica vaga. Es una estrategia manipuladora con el objetivo de conseguir algo, ya sea una ventaja estratégica o caer bien a la gente. Con este comportamiento me he topado varias veces, es traicionero, político y pasivo-agresivo. Suele darse en ambientes de trabajo tóxico. Si lo detectas huye.

Radical Candor no es una excusa para ser un gilipollas y tratar mal a tu equipo. Si actuas como un gilipollas, seguirás siendo un gilipollas. Radical Candor se centra en preocuparte de forma honesta y sincera por tu equipo. A la vez que desafías a cada persona de tu equipo para que mejore y desarrolle todo su potencial.

Os dejo la charla de Kim Scott por si la queréis ver.

He vidido un entorno toxico y he sobrevivido. Tú también puedes.

Josa Vicente — Mon, 05 Dec 2022 14:42:53 +0000

Lo primero que quiero decir y quiero que sirva de disclaimer antes de que nadie se sienta ofendido es que un ambiente tóxico
puede ser tan global o tan puntual como las circunstancias en una misma empresa. Una empresa no es tóxica, lo es la cultura que se promueve en ella o en parte de ella. Quizá promover
no sería la palabra porque creo sinceramente que casi todas estas situaciones son totalmente involuntarias, son fruto de la ignorancia de la gente y de como se promociona
en según que organizaciones. Es más lo que para mi puede ser tóxico para otros es lo más normal e incluso lo abrazan. Especialmente gente joven que quiere subir y mejorar
su salario de forma rápida.

Hay muchas entradas sobre señales de ambientes tóxicos o nocivos, pero yo tan solo voy a enumerar los que he vivido y como han influido en mi carrera. Todo esto es un analisis en perspectiva, teniendo que cuando estás en esos ambientes la mayoría de veces no lo sabes e incluso llegas a participar en algunas de las malas prácticas que aquí enumero. De hecho, estoy seguro que no solo he sido víctima sino verdugo. Pero es cuando sales y vives otros ambientes o culturas, cuando te das cuenta de ello.

1. Liderazgo negativo o inexistente ✔

La mayoría de veces esto ocurre porque la persona que debería liderar es alguien técnico que se le premia con una promoción y con unas funciones para las que no está preparado. En mi opinión esto ocurre porque en muchos entornos hay un tope para los perfiles técnicos en su crecimiento que o se pasa a una carrera más de management o te estancas en crecimiento y sueldo.

2. No respetar los horarios ✔

Típicas peticiones irracionales al final de la jornada laboral que acaban en trabajo tirado a la basura. Malas miradas de compañeros por irte a tu hora y comentarios cuestionando tu profesionalidad. Trabajar en festivos sin compensación económica, regalándote simplemente flexibilidad de entrada y salida. Llamadas al teléfono personal fuera de horas y otras prácticas del estilo.

5. Camarillas, exclusión y comportamientos chismosos ✔

Esto daría para una serie en Netflix.

4. Nulo feedback ✔

Con decir que en los últimos 6 años no he recibido feedback, creo que lo digo todo. Demasiado bien he salido creo yo.

5. Sientes que no puedes crecer dentro de la empresa ✔

Estacionamiento en el mismo rol a nivel de familia técnica en la empresa y económicamente. Pero asumiendo todo lo que se espera del siguiente rol para ti.

6. Mala comunicación ✔

Me remito al punto del feedback, de vez en cuando un mensaje de Teams preguntando que tal el proyecto. Camuflado con hacerte creer que: "es que lo llevas tan bien que es como si no estuviera el proyecto"

7. Reprimir el crecimiento ✔

Excusas vagas, patada adelante para las promociones. Esto puede ser en la forma de no poder cambiar de proyecto y/o tecnología usando argumentos tóxicos camuflados con elogios. Como ejemplo, elogiar lo especializado que estás en X, a la vez que hacerte sentir que o haces esto o no eres capaz de otra cosa.

8. Equilibrio entre la vida laboral y la personal ✔

He de decir que en este punto, a nivel horario y adaptabilidad a temas parentales, no tuve problemas. Pero el hecho de ser padre presente en casa me ha cerrado muchas puertas. Si yo que soy hombre blanco hetero normativo he sufrido este tipo de mobbing, no quiero ni pensar lo mal que se trata en muchos entornos y como se cortan las carreras de las mujeres, primero por ser mujeres y segundo si además quieren ser madres. Desde mi actual trabajo intento poner mi granito de arena para que de alguna manera esto cambie.

9. Ansiedad, dolor corporal, insomnio ✔

Creo que este punto habla por si solo.

Y ahora un resumen de actitudes que he visto y/o sufrido:

Calentar la silla.
Camarilla con el manager de turno.
Apropiación del trabajo ajeno.
Evaluación por horas extras realizadas (no pagadas) en lugar de por méritos.
Ignorar tu presencia.
No recibir ningún tipo de feedback.
Comentarios hirientes frente al equipo.
Machismo, esto obviamente lo he visto sobre gente de mi equipo y lo he peleado.
Menospreciar los méritos por ser mujer joven.
Menospreciar los méritos por tener gustos o físico considerados no normativos.
Aprovecharse de la jerarquía.

La luz después del burnout

Josa Vicente — Mon, 05 Dec 2022 14:39:11 +0000

Después del bajonero artículo sobre mi experiencia personal pasando por un burnout bastante largo (aunque inicialmente no lo identifiqué así), en esta ocasión quiero contar mi experiencia posterior. Obviamente, todo depende de que, ya sea cambiando de trabajo o cambiando de proyecto en la misma empresa, te encuentres con un entorno que te ayude a superar lo que has dejado atrás.

En mi caso personal, salí muy desmotivado y hundido de mi trabajo previo. El cambio, fue radical, salí de mi zona de confort, cambié de tipo de negocio, de tipo de entorno, de idioma, de forma de trabajar y para rematar en un equipo y proyecto que empezaba de 0. Ahora llevo un año y un mes y puedo hablar en perspectiva.

Lo que marcó la diferencia desde el primer minuto fue el equipo. Los compañeros de proyecto confiando en mí. Mi manager, que en nuestro primer 1:1 me transmitió confianza en mis capacidades y en mi capacidad de llevar al equipo. Otra cosa que me ha ayudado infinito es el feedback, sobre todo el feedback de lo que tenía que mejorar. Pasando de ser alguien que quería arriesgarse 0 por miedo al fracaso, a querer aportar y generar el impacto que pueda en lo que hago y en los demás. Tela, es que si no hubiese cambiado tanto, no estaríais leyendo esto.

El equipo tan solo fue la punta del iceberg, tras unas semanas, lo que me hizo ganar seguridad y confianza fue el entorno global, la comunidad. Tengo la suerte de trabajar en un entorno en el que se anima a tener iniciativa y pensar out of the box. El hecho de tener trainings de distintas índoles cada viernes, poder elegir tu foco en la formación y las sinergias entre equipos hacen que abras la mente y salgas de la tecnología que conoces para abrazar, ya no solo nuevas tecnologías sino nuevas formas de trabajar. Aquí no se trata solo de tu proyecto, las relaciones con los demás proyectos son posibles y tu voz se escucha más allá de tu proyecto.

No sé cuándo me hizo click, pero empecé a pensar a futuro, no al día a día. Tracé mi propio plan de cómo quiero que sea mi carrera en 2-3 años. Hace unos años ni me hubiese planteado los cursos que he hecho y que tengo en el pipeline para realizar. Ni se me hubiese pasado por la cabeza hacer katas en grupo, en seguida hubiese venido a mi mente que no era capaz, que se me juzgaría. Tenía tan metido en mi cabeza la competitividad y el "mi tesooooro", que no arriesgaba. Toda esta mentalidad al final es una suma de la personalidad introvertida que me caracteriza y los mensajes directos e indirectos que el entorno te lanza.

Puedo decir que he aprendido más en este año que en los anteriores 6. He dedicado horas a aprender, estudiar y leer sobre múltiples temas, más de las que hubiese dedicado si hubiese seguido sin arriesgarme y aceptando lo que había. Toda esta fuerza viene por la comunidad que me rodea y también, como no de un síndrome del impostor que lleva acompañándome toda mi carrera y que lo único bueno que me aporta es querer seguir aprendiendo para mitigarlo.

Viniendo del mundo consultoría y SAP, no voy a mentir. Muchos conceptos que leo en twitter nos los conozco o entiendo. He descubierto conceptos este año que no había escuchado o que si había escuchado había sido de pasada. Conceptos por los que ahora siento fascinación. Aunque ahora no puedo aplicarlos en mi día a día, ya que mi parte como IC es muy reducida en este momento, trato de aprender y mejorar por mi cuenta. Y ahora, no tengo miedo a no saber de algo, porque me rodea una comunidad que no juzga que no sepas de algo, todo lo contrario, te tiende la mano para ayudarte a aprenderlo. Y esto, no tiene precio.

Así que para quien lo lea, gracias, porque probablemente hayas contribuido de alguna manera a que salga de un burnout y a que ahora me muera de curiosidad y de ganas de cumplir el plan que tengo para mí yo de dentro de unos años.

Si algo puede resumir la etapa anterior y esta es: antes los domingos eran el peor día de la semana, ahora, son otro día más en el que pienso, que aprenderé la próxima semana.