Personalidades de los desarrolladores de software

En este post vamos a ver una lista de diferentes perfiles de desarrolladores que podemos encontrar en las empresas.

Este post esta basado sobre este en inglés (https://neilonsoftware.com/difficult-people-on-software-projects/developers/) no pretendo llevarme la autoria sobre el mismo, de hecho en el blog original los perfiles tienen muho mas detalle. Aquí los vamos a ver conforme a mi experiencia personal. 

 

Además indicar que en la lista no está el perfil “normal” en mi experiencia, de cada 100 desarrolladores, 50 son “normales” (o mayormente normales) y los otros 50 están repartidos en las siguientes categorías. 

 

 

El/La Rock Star

El primero que vamos a ver es el Rock star, la gran mayoría de los que estáis leyendo este post seréis developers lo que implica que tenéis linkedin y estoy seguro al 100% de que os ha llegado el típico mensaje de los recruiters que dice “buscamos un rock star”, o estamos montando un grupo de “rock stars”. En mi opinión hay muy pocos “rockstar” de verdad por ahí, y se cuentan con cuentagotas. 

 

Aún así si los dividimos al conjunto de una empresa los podemos diferenciar porque tienen las siguientes características:

• Son capaces de resolver todos los problemas que les mandan de una forma eficiente y rápida. 
• Su código apenas tiene bugs.
• Suelen coger las tareas más difíciles.
• Son una fuente de sabiduría para sus compañeros.

 

Por supuesto, tienen sus partes negativas

• Indispensables para el proyecto, Suelen tener conocimiento de absolutamente todo lo que pasa en el proyecto y de cómo se implementa, esto puede parecer un beneficio, pero es una parte negativa ya que si se van, nadie sabe como funciona nada.
• Arrogancia, todo el mundo sabe que en nuestro mundo hay mucha arrogancia, algunos de los que llamamos rockstar directamente tratan por idiota a todo el que no piense o vea lo que ellos ven.
• Todo tiene que estar hecho a su manera, como sabemos son capaces de detectar lo que necesitamos y directamente imponen sus opiniones o sus ideas.

Finalmente un efecto secundario cuando hay un rockstar en el equipo es que los compañeros empiezan a vaguear un poco, porque todas las tareas mediantanemten dificil con cogidas por el sujeto.

 

 

Aspirante a manager

Una vez cansado o agotado de los desafíos de ser un desarrollador, como pueden ser mantenerse al día y el reciclaje continuo. Nuestro sujeto ha decidido cambiar su visión de futuro en el trabajo para empezar a administrar personas. 

No hay nada que podamos hacer para evitarlo, al final es una decisión que “cambia su vida” y nada que le digas va a hacerlo cambiar. 

 

Sus características positivas son escasas, aun así tiene una que para mi es muy importante:

• Cuando el jefe no está, es el que lidera los meetings. 

Personalmente me considero un desarrollador y no me gusta en el meeting diario o en las retrospectivas, etc, el ir leyendo los tickets. De hecho la mitad de los meetings me los pasó trabajando. Mientras la gente habla de cosas que no me importan lo más mínimo. Gracias al aspirante a manager pese a ser el desarrollador con más experiencia no tengo que liderar dicho meeting. 

 

Pero desafortunadamente tiene importantes puntos negativos:

• Desgraciadamente ya pasa de programar y se pasa el día administrando gente o en demostrarle al jefe que merece cambiar a manager.
• Ya que se pasa el día “administrando” está todo el día en meetings, enviando emails Por lo que no se puede contar mucho con él para el desarrollo.
• Finalmente, para desgracia de todos, no tiene sitio en la empresa, él quiere ser manager, pero la empresa no necesita más managers, así que sus únicas esperanzas son. Que su manager se vaya, que la empresa crezca mucho para necesitar un manager nuevo o cambiarse de empresa. 

Aun así es buena gente, y le deseamos lo mejor a todo aquel que decida cambiarse a manager. En españa es muy común, ya que por norma general tienes que ser manager para cobrar más, lo que muchas empresas tienen managers que no quieren ser managers. 

 

 

Elefante en una cacharrería

En este punto tenemos un sujeto que lo único que le importa sobre el resto de cosas es terminar todas sus tareas e irse a casa, le da exactamente igual como esten, con tal de que “funcionen” (no lo hacen, al menos bien).

 

En los casos normales es que este sujeto se cree en función de la presión que el proyecto y las deadline generan, y quizá se haya pasado un año o incluso más, y ya ha cogido malos hábitos y no los ha soltado. 

 

Por supuesto, aquí tenemos muchos puntos negativos:

• Test? eso que es? se come? Debido a la deadline no se testea nada, ni de forma automática ni de forma manual.
• Lo cual causa tener el código lleno de bugs, cuando todo va bien, en el happy path, pues todo perfecto, pero cuando algo se tuerce, empiezan a saltar errores en todas partes.
• Esto es debido a que durante el desarrollo del mismo les da exactamente igual la calidad, han olvidado que son los principios SOLID y por qué son útiles, la frase revisión de código es algo que escucharon en su día y no saben ni donde se hacen. 

 

Desgraciadamente cuando tenemos un sujeto asi en nuestro equipo, es muy muy difícil “arreglarlo” la única solución es paciencia, tomarse sus reviews con calma y explicar cada detalle con los motivos de por que. Además explicarle que corriendo no va a llegar a ninguna parte, que mejor si hace el código bien, limpio y que se pueda mantener en el futuro.

 

 

El/La diva

Persona completamente convencida de que es irremplazable la cual se convierte en un tanto arrogante.  

 

Como características principales podemos incluir las siguientes:

• Buenos developers, pero no tan buenos como un Rock Star, aunque dicho sujeto piense lo contrario. 

 

y por ende sus contras:

• No trabajan para la empresa, en el fondo en su cabeza hacen lo que quieren y a su modo, de hecho piensan que todo está mal y no siempre hacen caso a su manager.
• Se piensan que son irremplazables, en su cabeza nadie sabe hacer nada y todos hacen todo mal, así que nunca pueden pensar que los van a despedir porque “nadie sabe más que yo”.
• Por ese motivo van con unos aires de grandeza y un ego que no entran por la puerta, y les da igual lo que otros les digan, incluido su manager.

 

 

El/La que sobreestima las tareas

Típica persona que, cansada de no llegar a las deadlines que ya han llegado a un punto en el que piden por mucho tiempo más del que necesitan

 

Por norma general suele ser mejor que vas a decir que vas a tardar más que menos.

• El que sobreestima sabe que lo hace y es consciente por lo que en verdad todo debería estar acabado antes, y bien testeado.

 

Los puntos negativos son más para el jefe o el emprendedor que para los compañeros 

• Tiempo, todo lo que quieren es tiempo lo cual es bastante ineficiente para la empresa.
• Lo que implica que sus estimaciones no tienen valor ninguno, si dicen un tiempo y lo reduces un 20% aceptaran el cambio igual que si alguien lo amplia.
• Desafortunadamente para los compañeros que quieren aspirar a managers, este tipo de developers suelen tener muy buena imagen de cara a los jefes de los jefes ya que claro, siempre llegan a sus deadlines, y el trabajo está completo, así que muchas veces se hacen con esos puestos. 

 

 

El/La que Subestima las tareas

Justo al contrario que nuestro sujeto anterior, el que subestima siempre acorta el tiempo que dice que va a tardar para completar una tarea. 

La verdad que en este perfil no tenemos muchos puntos positivos por no decir ninguno.

En cambio si tenemos varios puntos negativos

• Nunca llega a tiempo, como siempre está diciendo que va a tardar menos de lo que va tardar al final se hacen las cosas rápido, mal y comúnmente, tarde.
• Debido a que sus estimaciones no tienen sentido ninguno no podemos estimar una ruta de desarrollo clara para nuestro proyecto.

 

Es sabido por todos en la industria que es muy común indicar menos tiempo del necesario para las tareas, pero en este caso es extremo. Además suelen pensar que estimar no sirve de nada.

 

Personalmente diré que para mi estimar no es extremadamente importante, si bien es cierto depende del proyecto y de los participantes, pero como yo mejor trabajo, es con un, para este día, todo esto tiene que estar, no tener que ir estimando tarea por tarea. Pero esto es una opinión personal. 

 

 

El/La secuestrador/a de código

Típico personaje que ha escrito una parte del sistema que es crítico para que la empresa no se caiga en pedazos y no deje que nadie lo toque.

Gracias a dios este perfil se va viendo cada vez menos con la llegada de los microservicios y las aplicaciones distribuidas, pero aún así, sigue existiendo.

 

Cuando hablamos de un secuestrador de código, hablamos de una persona que ha trabajado, la mayoría del tiempo en una parte del mismo, y lo trata como a su hijo, y lo conoce como tal. Y por lo tanto no lo quiere compartir.

 

Porque además tiene claro que mientras nadie más conozca el código o cómo funciona, su puesto en la empresa está seguro. 

 

Eso sí, cuando se vaya, que se irá, será un problemón para el que venga detrás.

 

 

El/La idealista de código

El sujeto de este punto está obsesionado con hacer un código elegante y perfecto que se ha olvidado completamente de que trabaja para una empresa la cual quiere resultados.

 

Por supuesto estar concentrado en la calidad nos trae beneficios 

• El código es bueno, un idealista destaca por hacer código elegante, legible y mantenible, lo cual es bueno, quizá algunas veces se pasen de “cool” y añaden más complejidad de la necesaria.
• Por norma general el código estará testeado y retesteado lo que evitará tener bugs o fallos en producción.
• De hecho son buenos developers, y con todo el tiempo del mundo te podrían montar el sistema entero si fuera necesario. Tienen un buen nivel general en todo y expertos en una o dos áreas (backend/frontend/devops) mínimo.

 

Pero desafortunadamente también tienen puntos negativos 

• Pese a lo que el idealista piensa, no tiene todo el tiempo del mundo, y las tareas y funcionalidades tienen una fecha límite para estar terminadas y presentarselas a los clientes, y que estos paguen a la empresa y esta a nosotros, el idealista se olvida de ese detalle, añadir valor de negocio.
• Muchas veces no tiene que estar todo el código como si Picasso lo hubiera pintado, basta con hacer las cosas simples y rápidas, con un mínimo de calidad, obviamente, pero nada llevado al extremo.
• A diferencia del caso anterior donde un developer secuestraba código, nuestro idealista secuestra personas para llevarlas a su causa, es el sueño de todo desarrollador el tener todo el tiempo del mundo y hacer las cosas bien. Lo que implica un mayor impacto para el proyecto. 

El sujeto idealista es un buen sujeto, de hecho es un muy buen desarrollador, y piensan de verdad que hacer las cosas extremadamente bien será lo mejor para el futuro de la empresa.

En las empresas punteras es donde más destacan ya que estas no tienen unos tiempos tan ajustados y tienen margen económico para unos meses o incluso unos años.

Pero, si la empresa es pequeña, está condenado al fracaso/frustración ya que los jefes querrán ver los resultados. 

 

Si tuviera que elegir un punto en el que me siento identificado, este sería sin lugar a dudas.

 

 

El/La incompetente 

Desgraciadamente todos tenemos compañeros que les falta esa chispa para ser buenos escribiendo código.

 

Por el mismo motivo que no todo el mundo puede ser futbolista o músico no todo el mundo puede escribir código.

Además personalmente noto que está empezando a ser más común, y es debido al elevado nivel de sueldos en informática, todo el mundo se mete a programar y claro, no todos valen, y lo que es peor, a muchos no les gusta, y lo hacen únicamente por el dinero. 

 

Personalmente pienso que programar puede ser un trabajo muy estresante, si estás leyendo esto y estás únicamente por el dinero reconsideralo muy seriamente, ganarás en salud. 

 

También decir que suelen ser personas que no se están tocando la barriga, sino que están ahí pico y pala probando hasta que encuentran la solución o se dan por vencidos y ya piden ayuda. 

 

El problema viene cuando tienes más de uno en el equipo y principalmente son los siguientes:

• Revisar su código. Necesitan una supervisión constante, ya que el código suele tener un montón de bugs, o incluso las características del ticket no están completas al 100%, lo cual puede llegar a ser frustrante.
• Suelen quejarse de que sus tareas no las pueden completar debido a una falta de training, y cuando les preguntas qué tal van, te saltan a la defensiva, siempre tienes que indicar que estás ahí para ayudar.
• Comúnmente intentan aplicar por todas las ofertas para managers, ya que están frustrados como desarrolladores. 

Personalmente, pienso que todo el mundo puede aprender, en IT hoy en día entra todo el mundo, y la mejor forma de tratar con este sujeto es con paciencia y explicando las cosas con detalle, una o diez veces, mientras preste atención, puedes repetirlo tantas veces como necesites. No seas una diva. 

 

 

El/La soldado de la empresa

Típico compañero que hace lo que le mandan, sin preguntar, y sin cuestionarse si está bien o no.

 

Desde el punto de vista de la empresa ao del manager, las características del soldado son perfectas:

• Hace lo que le mandan, ni una línea de código más, ni una menos, cumple, y para casa.
• El “nivel” del soldado puede ser cualquiera desde un incompetente a un rockstar.

 

Pero pese a ser un buen empleado, tener soldados tiene sus partes negativas:

• No dan opinión, han llegado a un punto en el que hacen lo que les mandan, y no se quejan, y ni siquiera dan opiniones de como mejorar, sepan o no como.
• Si saben que algo está mal, no te lo van a decir, y van a hacerlo igual, y luego verás reflejadas las consecuencias. 
• Este tipo de personas están así porque la empresa “los ha formado” como si de una dictadura se tratase, obedientes, pero libres, lo que implica que estén buscando nuevos trabajos constantemente y a la mínima se van a marchar. 

 

 

El/La loco/a de la tecnología

Hemos llegado a un punto en el que hay frameworks de javascript nuevos cada día o nuevas tecnologías de forma diaria, nuestro sujeto es un/una apasionado de absolutamente todo lo que sale, y como tal, lo quiere probar, por supuesto en la empresa. 

 

Tener un empleado así o un compañero puede ser muy beneficioso ya que al haber tocado y experimentado tanto en el pasado, tiene ideas en la cabeza que pueden ayudar de una muy buena manera al funcionamiento de nuestro proyecto. Imagina que nunca has trabajado en la nube, nuestro sujeto, tendrá una pequeña idea de como puede ser un sistema en la nube, ya sea porque lo ha tocado en casa o en su empresa anterior. 

 

Esto tiene su parte positiva, obviamente, pero también tiene la parte negativa de que sus ideas personales de aprender o de intentar mejorar en alguna tecnología, hacen que su elección no sea siempre lo mejor para la empresa.

 

Esto es debido a que si decide que quiere aprender java o node cuando todo tu código esta en C# puede darse el caso de que tengas todos los microservicios en C# menos uno, el que le dio a nuestro sujeto por experimentar.

Lo mismo pasa con bases de datos o cualquier tecnología. 

 

Muchas veces pueden tener razón  y por eso es importante, cuando tenemos una persona así en nuestro equipo, explicarle que hay un stack fijo, pero que si ve que algo se puede mejorar, es libre de crear una presentación que lo justifique. 

Y así estamos todos contentos, los compañeros, la empresa y él.

 

 

El/La chapado/a a la antigua

Persona que su única habilidad es mantener código antiguo (legacy) pero es incapaz de utilizar nuevas tecnologías o crear algo nuevo. 

Seamos sinceros, nadie quiere mantener código viejo, la gran mayoría de nosotros, y posiblemente el 100% de los que estáis leyendo este post queremos crear nuevos procesos, nuevas aplicaciones, todo nuevo todo el tiempo, por lo que tener una persona que no quiera cambiar no es completamente negativo. 

 

Casi siempre puedes sentirte libre de asignarle todos los bugs y todos los cambios menores que requieren cierto conocimiento del dominio para ser ejecutados, ya que este sujeto habrá trabajado durante años en ese código y se lo conoce a la perfección. 

 

Ahora eso si, es casi imposible convencerlos de cambiar o mejorar, en el mundo de los microservicios no hay tanto problema, pero en los monolitos es muy complicado intentar aplicar cualquier cambio o mejora, ya que sus respuestas cuando le digas que tiene que hacer X o Y van a ser del tipo “siempre lo hemos hecho así”, “Tardamos mucho en hacer esto, no lo vamos a rehacer” y demás para intentar evitar su cambio.

 

Además el hecho de que no quieran cambiar, puede desmotivar a nuevos integrantes del equipo, o incluso a integrantes más antiguos cansados de sus excusas y evasivas. 

 

Gracias a dios, este tipo de sujetos no suele llegar a manager,pero cuando lo hace la empresa corre un grave peligro, directamente nunca se va a actualizar, va a hacer todo lo que pueda para denegar todas las mejoras y indiscutiblemente la empresa está destinada al fracaso. 

 

 

Conclusión

 

En este post hemos visto diferentes perfiles dentro del mundo del desarrollo de software.

 

Por supuesto no todo el mundo entra en uno o en otro, sino que suelen ser combinaciones de varios, así como su parte de “normal”.

Desgraciadamente para muchos mantener código antiguo no es una opción sino una obligación, y pese a que les gustaría cambiar debido a la empresa no pueden. A todos estos, mi más sentido pésame. Estudiad y cambiad de empresa, ganareis en salud.