🧵 De desarrollador junior a manager senior en un camino. Una carrera profesional en un hilo

Dev junior.

Te dicen: Hay que ir ahí! Mientras te señalan un punto en el horizonte.

Trazas una línea recta mental desde donde estás hasta el punto y la sigues. Ante el primer obstáculo te quedas bloqueado y no dices nada.

Te terminan llevando a algún lugar. No sabes cuál

Dev mid.

Eres capaz de sortear obstáculos pequeños y levantar la mano cuando necesitas ayuda.

Haces equipo con una compañera y termináis llegando a algún sitio cerca de donde te señalaron

Dev senior.

Eres capaz de sortear los obstáculos solo y ayudas a tus compañeros.

A mitad de camino te das cuenta de que hay un sitio mejor al que ir y avisas a todo el mundo

Manager junior.

Te tiras semanas escondido haciendo un mapa detallado.

Durante el camino, corriges cualquier paso mal dado. No admites réplicas.

Llegáis tarde a un sitio que no sirve de nada. Dices que ha sido un éxito porque lo dice el mapa y la culpa es de la estimación

Manager mid.

Enseñas el mapa antes de salir y hacéis correcciones.

Se te pierde gente por el camino, pero los encuentras.

Piensas que vais a llegar tarde. Decides cambiar la ruta. Nadie te entiende del todo. Pero termináis en un sitio decente

Manager senior.

Explicas a dónde hay que ir, por qué y cuánto tiempo hay.

Hacéis el mapa entre todos.

Te aseguras de que se lleva un ritmo sostenible y la gente se ayuda entre sí.

A mitad os dais cuenta de que es mejor ir a otro sitio diferente. Reconoces tu error. Llegáis

DISCLAIMER:

No te lo tomes muy en serio. Esto no deja de ser una metáfora o un cuento. Y como todas las metáforas, según tu contexto, aplicará mejor o peor

De desarrollador junior a manager senior: un camino, una carrera

🧵 Los tests programados son una herramienta para obtener feedback.

Según el momento en que usemos los tests, nos darán un tipo de feedback diferente.

Lo vemos? 👇 

Momento 1: Antes de escribir el código de aplicación.

El conocido Test First o TDD.

Nos dará un feedback sobre el diseño que tenemos en mente.

Es esta la forma en que quiero que se use mi código?

Momento 2: Después de escribir el código pero antes de probar de forma manual.

Nos dará feedback sobre si nuestro código se comporta como debería.

Estoy escribiendo el código de forma correcta?

Momento 3: Después de probar de forma manual.

Puede que nos dé feedback de algún caso de prueba que hemos obviado o no se podía probar manual, pero sobre todo creará una red de seguridad automática para el futuro.

Alguien ha modificado el código existente y ha roto algo?

Los momentos son, digamos, acumulativos.

Al feedback del momento 2 se suma el del momento 3. Y al del momento 1, se suman el del 2 y 3.

Resulta, que parece que Backend y Frontend tienen momentos preferidos diferentes a la hora de programar tests.

Backend se centraría sobre todo en el momento 2. Mientras que Frontend preferiría el 3 o directamente no hacer tests

https://x.com/jcesarperez/status/1848722851500855720

Yo no soy Frontend, pero me niego a pensar que los de Frontend programan peor o saben menos que los de Backend.

Entonces qué pasa?

DISCLAIMER: Sí, estoy generalizando, voy a hacerlo un poco más y no he hecho ningún estudio empírico serio

Para un backend, suele ser más fácil y rápido pobar su código programando un test que probar de forma manual.

Reiniciar la aplicación, levantar dependencias, poblar bases de datos, configuraciones, son tareas que llevan su tiempo como para hacerlas con cada prueba

También a la hora de comprobar el resultado del código. Incluso aunque uses postman o similar, es más sencillo escribir un assert que ponerte a explorar algunas respuestas json e ir a la base de datos o una cola de mensajería para comprobar que se ha comportado como debería

Pero para un frontend, es diferente. Sobre todo si ya tienen el backend montado.

Sí, es cierto que hay muchas funciones que se prueban muy fácil con tests unitarios.

Pero al final siempre necesitan comprobaciones visuales y su código despliega rápido

Como decía, los tests son una herramienta excelente para obtener feedback. 

Son una herramienta muy efectiva. En algunos contextos más que en otros. Pero no son la única

Los tests vienen con costes. Los tests son código. Y como todo código hay que programarlo, hay que mantenerlo y hay que ejecutarlo.

Hay que diferenciar qué partes requieren invertir un coste mayor en tests y cuáles uno menor. O incluso ninguno!

Porque qué valor tiene un test que nunca se puso rojo?

Se creó, se ejecutó varias veces, siempre verde. Hasta que la funcionalidad cambió y el test dejó de existir como tal

Entonces habría que probar más de forma manual?

No he dicho eso. Dependerá mucho de tu contexto. Pero a lo mejor hay que gente que abusa de los tests.

Recordemos tb que los tests no garantizan que tu código no tiene errores. Los tests sólo prueban que hay errores cuando los hay

Hey, Julio! Pero entonces estás diciendo que en Frontend no hay que programar tests?

NO. En Frontend hay que usar tests. Pero la forma de programar tests, no tiene por qué ser la misma que en Backend. No suele serlo. Y está bien

En resumen:

Los tests son una herramienta de feedback.
Los tests hay que usarlos de forma efectiva para que aceleren nuestro desarrollo.
Dependiendo del contexto, la forma puede variar u otras herramientas pueden ser efectivas tb.
Frontend y Backend son contextos muy diferentes

Tests are tools to get feedback

🧵 Una dev que va a cambiar de empresa y ser manager por primera vez me ha pedido un café esta semana para ver si puedo darle algunos consejos para su nueva aventura.

No es algo que se pueda improvisar, así que voy a escribir algo para ayudarme a pensar.

Allá va

Cambio de foco.

Ya no eres un indivual contributor. Mira que me gusta poco el término, pero es verdad.

Un manager impacta a través de:

- Los resultados de su equipo
- Su influencia en las personas y la organización. Llámalo liderazgo, si quieres

Una pregunta típica es: Debe un manager programar?

Antes o después dejarás de programar. Si pasas a manager en la misma empresa, donde ya conoces el código y la tecnología, es fácil seguir programando.

Pero es lo que deberías hacer?

Si la mejor forma que tiene un manager de impactar es programando, es porque algo pasa.

Puede ser temporal porque el equipo realmente lo necesita ahora. Pero puede que no sepa cómo impactar como manager. O puede que el equipo necesite mejores programadores

Paciencia.

Alcanzar una posición donde tienes impacto como manager lleva su tiempo. Si eres nuevo en la empresa, más.

El impacto del manager no es inmediato. Tus acciones necesitan tiempo para tener resultados. No estás acostumbrado a ello. Paciencia...

No quieras cambiarlo todo, pero asegúrate de que llevas a cabo acciones.

Mide la temperatura del equipo a tu llegada y cuánta resistencia ofrecen a los cambios. Sé prudente, sé inteligente, pero sé valiente también.

Detecta algún quick-win, busca algún aliado y llévalo a cabo

Crea relaciones.

Dentro del equipo por supuesto. Pero también fuera.

Llegar como manager a una empresa nueva puede ser un trabajo muy solitario. Busca algún compinche fuera del equipo que te dé contexto y te apoye. Lo vas a necesitar

Y esto es un poco lo que se me ha ocurrido.

Se te ocurre a ti algún consejo más que pueda darle?

Consejos para un Nuevo Manager

🧵 Creéis que la actitud en el trabajo se hace o se nace?

El otro nos dieron un workshop sobre sistemas complejos y, entre muchas cosas, nos explicaron las teorías X e Y de McGregor, sobre la conducta en el trabajo


Luego nos preguntaron qué % de personas creíamos que eran del tipo X.

Casi todo el mundo respondió con un porcentaje muy elevado. Mayor que el 75%. Algunos incluso mayor que un 90%

Tú qué habrías respondido?

A continuación nos preguntaron qué tipo de personas éramos nosotros?

Todos respondimos Y.

Tú qué habrías respondido?

Éramos un grupo de 12 personas y, según nosotros, la mayoría de personas eran de tipo X, pero nosotros en concreto éramos de tipo Y. Todos nosotros.

Algo no cuadra.

Ay el ego...

En realidad, las personas no son de tipo X o Y de serie. Es el sistema de organización del trabajo lo que provoca que las personas se comporten según el tipo X o Y.

La actitud se hace, no se nace

Si como manager, crees que la mayoría de personas son de tipo X, que no tienen la actitud adecuada, es más probable que seas tú el que está provocando ese comportamiento con tu sistema de trabajo.

Mírate a ti mismo y mira el sistema, antes de echar la culpa a los demás

Entonces, cómo promover esa actitud tan deseada?

Aún tengo que recibir la 2a parte del workshop, pero mi apuesta va por la teoría de la Motivación Intrínseca basada en promover: propósito, autonomía y maestría.

Pienso que si fichas bien y eres honesto con las expectativas, la gente viene motivada de casa.

Luego es cuestión de no cagarla. Crea un entorno de confianza y transparencia, en lugar de uno de control, de palo y zanahoria, y encontrarás la actitud deseada

La actitud en el trabajo se hace o se nace?

🧵 Creéis que la actitud en el trabajo se hace o se nace?

El otro nos dieron un workshop sobre sistemas complejos y, entre muchas cosas, nos explicaron las teorías X e Y sobre la conducta en el trabajo

A continuación nos preguntaron qué tipo de personas éramos nosotros?

Todos respondimos Y. Éramos un grupo de más de 10 personas.

Tú qué habrías respondido?

O sea que, según nosotros, la mayoría de personas eran de tipo X, pero nosotros en concreto éramos Y. Todos nosotros.

Algo no cuadra.

Ay el ego...

En realidad, las personas no son de tipo X o Y. Es el sistema de organización del trabajo lo que provoca que las personas se comporten según el tipo X o Y.

La actitud se hace, no se nace

Si como manager, crees que la mayoría de personas son de tipo X, que no tienen la actitud adecuada, es más probable que seas tú el que está provocando ese comportamiento con el sistema de trabajo

Entonces, cómo promover esa actitud tan deseada?

Aún tengo que recibir la 2a parte del workshop, pero mi apuesta va por la teoría de la Motivación: propósito, autonomía y maestría.

Y sobre todo, por no desmotivar y trabajar en un entorno seguro

🧵 Un enemigo de los entornos 10x es La Bronca.

La bronca es siempre una comunicación violenta, especialmente cuando viene de alguien con poder sobre ti.

La bronca te la echa un manager, pero también un senior o alguien que se cree senior

La bronca parte de un juicio sobre la persona que la recibe.

En el mejor de los casos, el juicio es correcto. Hay personas que llevan relativamente bien lo de recibir broncas. No es mi caso.

Cuando no lleva razón, el daño se multiplica

La bronca daña la autoestima y genera inseguridad, desalineamiento, frustración, rencor e incluso temor.

Digámoslo claramente: la bronca desmotiva y crea un entorno de inseguridad y ocultación.

La bronca también crea una relación de dependencia.

La gente trabaja centrada más en no recibir broncas, que en hacer bien su trabajo.

Esto mina la autonomía y la iniciativa. Sobre todo si le sumas un poco de micromanagement

La bronca puede tener resultados a corto plazo. O al menos eso suele creer el que echa la bronca.

Pero a largo plazo es fatal. Dificulta el crecimiento de las personas, afecta a las relaciones y desmotiva fuertemente. Hasta el punto de poder llegar a ser un motivo de burnout

Quiere esto decir que no puede haber discusiones?

No. Habrá discusiones y desacuerdos, como en todas las relaciones entre personas.
Pero las discusiones deberían resolverse de forma no violenta. Sin gritos, sin faltas de respeto. Sin que te echen una bronca

"Pero es que yo hablo así"

Pues aprendes a hablar que ya eres mayorcito. Estamos en 2024, esto es una empresa tecnológica y tú no eres el sargento de la Chaqueta Metálica.

Aprendes a comportarte de forma profesional

En definitiva, la bronca es la herramienta del mediocre. Más cosmética que efectiva. Un signo de la cultura de palo y zanahoria que está demostrado ser un desmotivador, especialmente en entornos complejos y de trabajo intelectual.

Huye de los entornos donde la bronca sea común

Por el contrario, no tener broncas es el primer paso para tener un entorno seguro y de confianza.

Las personas serán más abiertas y transparentes. Serán más propensas a tomar la iniciativa y ser más autónomas.

Estarán más motivadas

Si te perdiste el hilo de los entornos 10x, por aquí te lo dejo 👇 
https://x.com/jcesarperez/status/1771877194127876209?s=20

La Bronca

🧵 Mucho se habla de las personas 10x y poco de los entornos 10x.

Cómo sería un entorno 10x?

Tiene una alta colaboración.

Las personas trabajan codo con codo a diario. Se ayudan y comparten información. Se sienten un equipo, saben que juntos trabajan mejor y están predispuestos para echar una mano al compañero

Existe una comunicación efectiva.

A todos los niveles. Se usan los canales adecuados para cada comunicación. Síncrono o asíncrono. Tienen las reuniones justas y son reuniones bien gestionadas.

Pero también a nivel de los canales, tickets y documentación

Todo el equipo tiene claro cuál es su objetivo a largo plazo.

Pero también a corto. Saben qué hay que hacer esta semana y qué hacer cuándo terminen.

Está bien organizado sin necesidad de micromanagement

Es un entorno seguro y abierto.

No hay miedo a hablar. No hay malas formas. No hay broncas. No hay desconfianza. No hay culpas. No hay cotilleos.

Todos respetan a sus compañeros y se sienten respetados

Se saben gestionar los errores.

Hay responsabilidad, pero se entiende que cometer errores es natural.

Se pone el foco en arreglarlo e intentar evitarlo en el futuro

Hay un espíritu de mejora continuo.

Existe satisfacción por el modo de trabajar, pero a la vez se busca mejorar.

Se sugieren cambios a menudo, que se reciben de forma abierta, se hablan y se prueban.

Si se mira atrás, se ve una trayectoria de adaptación y cambio al contexto

Hay un sano sentido de pertenencia y de reconocimiento.

Existe cierto orgullo por la forma de trabajar y el software construido.

Se celebran los logros obtenidos

En definitiva, un entorno 10x es un entorno que potencia a todas las personas que forman parte y donde da gusto trabajar.

Da igual que antes fueras 1x, 2x o 0,5x. Dentro vas a rendir multiplicado y vas a crecer de la mano de tus compañeros

Entorno 10x

🧵  Cuántas personas de Producto hacen falta para cambiar una bombilla?

1 Researcher para entender los problemas y necesidades de iluminación del usuario en general, y en esa habitación en particular.

1 Researcher Manager para gestionar al anterior.

Van 2

1 Product Analyst para analizar las características de todas las bombillas disponibles y obtener las métricas desde distintos puntos de vista.

1 Product Analyst Manager para gestionar al anterior.

Van 4

1 Product Manager definiar el impacto de cambiar la bombilla y priorizar la iniciativa.

1 Product Lead para gestionar al anterior.

Van 6

1 Engineer para cambiar la bombilla.

1 Engineering Manager para gestionar al anterior.

Van 8

1 QA para probar que la bombilla se enciende y apaga al pulsar el interruptor.

1 QA Manager para gestionar al anterior.

Van 10

1 Scrum Master para... No, mentira. Éste no es necesario.

Son 10 en total

DISCLAIMER: Es sólo humor.

He considerado que el engineer es full-stack para no hacerlo más largo

Cuántas personas de Producto hacen falta para cambiar una bombilla

DEPENDE.

Lo ideal, por respeto al candidato, es hacer la entrevista cultural antes y filtrar. Así le evitas el sacrificio de horas de la prueba técnica. En especial si no tienes pensado hacer siempre entrevista técnica después de la prueba.

Pero...

https://x.com/andreualfonso/status/1740669483826692383?s=20

El proceso de selección debe diseñarse para ahorrar costes.

Hay puestos donde se pueden recibir multitud de CVs muy similares y que no te sirven para filtrar. Pej. juniors.

Tiene sentido hacer la prueba técnica antes y que además sea fácil de corregir. Incluso automática

También si son puestos donde se espera un alto % de rechazo en la prueba técnica, tiene sentido hacerla antes.

Otra opción es que sean sitios donde el tiempo del manager que hace la entrevista sea muy costoso 🚩

Y es que el proceso de selección dice mucho sobre la empresa:

Cómo piensan, qué cosas valoran más que otras, cómo de fuerte es tech y qué cultura tienen

Optimizando el proceso de selección

🧵 Me pide Manu que explique por qué creo que trabajar con Pull Requests bloqueantes se ha convertido en cargo cult.

Los motivos principales son 2:

1. Todos llevamos un pequeño gatekeeper dentro
2. Promueve un modo de trabajo fácil a corto plazo

https://x.com/evrtrabajo/status/1723276848883196341?s=20

1️⃣ Todos llevamos un pequeño gatekeeper controlador dentro.

Nos decimos a nosotros mismos que es por la calidad del código. Por la deuda técnica. Que hay que hacer revisiones.

Pero luego todos sabemos la calidad de código y deuda técnica que hay en nuestros repos

Sí, claro que hay que hacer revisiones. Pero hay muchos tipos de revisiones y momentos para hacerlas.

Bloquear todo por defecto durante horas o días por un feedback que la mayoría de veces no corrige bugs es super inefectivo.

Dejemos que el dev sea responsable de decidir qué revisiones necesita. Incluido las bloqueantes.

Si el código funciona, no hay por qué bloquearlo por defecto. Esos cambios se pueden hacer después. No tiene ni por qué hacerlos la misma persona

Si de verdad nos preocupa la calidad del código hay herramientas que son mucho más efectivas:

- Análisis de código estático
- Tests
- Refactoring continuo

Entonces, si las pull requests bloqueantes no son efectivas. Si la calidad de nuestro código sigue siendo deficiente aunque pongamos 2 aprobaciones obligatorias. Por qué lo hacemos?

Porque nos da una falsa sensación de control

2️⃣ Promueve un modo de trabajo fácil a corto plazo.

Empiezo un ticket, programo aislado durante días en mi rama, me dan un OK, cierro ticket.
Una vez cerrado, si pasa algo, digo que yo hice lo que ponía el ticket y si eso que me abran otro ticket.

A quién no le va a gustar?

Este modo de trabajar promueve que el dev se convierta en un mero despachador de tickets. De nuevo, le quitamos responsabilidad y con ello, frenamos su iniciativa.

Pero además sabemos que no funciona.

En los proyectos que van mal siempre escuchas la misma queja: los devs no tienen iniciativa.

No la tienen porque no lo estás promoviendo. Se la has cortado desde el principio.

El trabajo de un dev debe ser resolver problemas llevando software a Producción. No resolver tickets

Es un trabajo más complicado, que requiere mucha más colaboración con personas, implicación y momentos incómodos.

Pero es el trabajo que funciona

Y esto de forma resumida sería todo. Espero que a Manu le haya gustado.

Tenemos ego, falsa sensación de control y comodidad como incentivos.
Era fácil que se convirtiera en cargo cult.
Lo difícil es cambiarlo