Anoche estaba repasando mi currículum que me trajo recuerdos de mis entornos de trabajo anteriores. He estado en la industria del software durante 10 años, desde analista de datos (no tengo un título en informática), a programador junior, a desarrollador de software, a desarrollador senior, a líder tecnológico (todavía programando y me gusta), principalmente C y C++ con algunas diligencias en diferentes ámbitos. Y esto es lo que no me da descanso:
Nadie. Es más, ni siquiera conozco a nadie que haya oído hablar de alguien que haya sido despedido por un código incorrecto.
Estoy haciendo hincapié en el código incorrecto porque presencié el despido de personas (o al menos las presiones para que se fueran) por no tener código, tipos que no podían resolver tareas simples en absoluto; no importaba cuánto tiempo se le diera, nada funcionaba ni remotamente.
Pero tan pronto como alguien es capaz de escribir cualquier cosa que pueda agitarse con la mano como "listo" o "hecho", un campo de fuerza parece rodearlo. Y no importa si el código "hecho" está repleto de errores fáciles de evitar que nos molestan en el control de calidad o por parte de los clientes enojados, o si está reinventando constantemente las rutinas presentes en la biblioteca estándar, o si es extremadamente complicado ( paginasde código que podría reducirse a unas pocas docenas de líneas, sin exagerar), o no pone el más mínimo esfuerzo en factorizar las rutinas de uso común (solo copia y pega repetitivo), o tiene nombres de variables que no tienen nada que ver con los valores sostienen. Incluso si algunos de los anteriores desangran numerosos días-hombre de un proyecto para la corrección de errores, ciclos de control de calidad adicionales, horas adicionales para la depuración porque otros miembros del equipo no pueden resolverlo, horas adicionales para la refactorización porque algún miembro del equipo quiere averiguar fuera - no ruedan cabezas.
Para ser claros, no soy partidario de apuntar con armas a las personas porque cometieron un error. Todo el mundo los hace, incluso los mejores desarrolladores que he visto tropiezan a menudo al principio (rara vez más adelante). Estoy hablando de casos seleccionados que cometen este tipo de errores una y otra vez a pesar de ser señalados en las revisiones de código. Y estoy dejando de lado deliberadamente problemas "pequeños" como no seguir las convenciones del código para concentrarme en las cosas que causan un daño real.
Eso me deja perplejo. En todos los proyectos en los que he estado, siempre se hizo hincapié en el tiempo, la calidad y, en consecuencia, la rentabilidad, pero no se eliminó a las personas que obstaculizan repetidamente los tres. Al principio pensé que era porque el conocimiento técnico generalmente se distribuye en la parte inferior del organigrama, pero noté que las manzanas podridas fallan no solo al escribir código. A menudo escriben documentación ilegible, generan informes de errores de baja calidad (faltan elementos básicos como versiones de software o incluso cuál era el problema), tienen malas habilidades de comunicación por correo electrónico; en general, son trabajadores deficientes. De modo que la gerencia puede verlo y esa información se filtra hacia arriba (se ha insinuado muchas veces durante una pequeña charla que saben quién "es inútil").
En todos mis 10 años de experiencia, los programadores que escriben mal código han sido constantemente recordados (y burlados) por sus compañeros que lo que hacen duele, alentados y reprendidos por la gerencia intermedia para hacerlo mejor, pero nunca despedidos. En los casos en que las habilidades deficientes se combinan con la tendencia a provocar conflictos, sus carreras a veces se estancaron. Pero si son superficialmente cooperativos, lo hacen bien y, a veces, son ascendidos a puestos superiores y de arquitecto.
¿Es normal en toda la industria que las personas no sean despedidas por escribir código incorrecto? Si es así, ¿por qué? Y lo que es más importante, ¿cómo lidiar con los reincidentes si eliminarlos no es una opción?
También he visto a personas que consistentemente escribieron mal código dejarlo ir antes. Si bien no estaban en el circuito de Recursos Humanos/Administración en ese trabajo, generalmente los despedían al final de un proyecto porque "no había ningún trabajo disponible". Todos los miembros del equipo productivo estaban cubiertos en nuevos proyectos, pero cuando ha generado una reputación de inútil, ningún PM querrá llevarlo a su proyecto, por lo que "no hay trabajo disponible".
Las personas son despedidas por ser malos programadores. Pasa todo el tiempo. Escribir mal código es solo uno de los síntomas de ser un mal programador. Otros síntomas tardan una eternidad en realizar incluso las tareas más sencillas y una incapacidad constante para trabajar sin una estrecha supervisión. Más a menudo, las palabras que se usan para justificar dejarlos ir son "bajo rendimiento" o "no cumplir con las expectativas".
La mayoría de los lugares probarán una, o ambas, de dos opciones antes de soltar a alguien. En primer lugar, intentarán encontrar un trabajo dentro de la empresa que se ajuste más a sus capacidades y animarán a la persona a moverse en esa dirección. En segundo lugar, les notificarán su bajo rendimiento y les exigirán que muestren una mejora, ya sea de manera informal o formal a través de lo que comúnmente se denomina Plan de mejora del rendimiento (PIP). En general, un PIP se considera como la última prueba que recopila la empresa, por lo que tienen un registro en papel que dice que intentaron rehabilitar al trabajador deficiente, pero no tuvieron éxito. Luego dejan ir a la persona por no mostrar mejoría.
Bernardo Barker
Bernardo Barker
Una lechuza
paparazzi
Hombre enmascarado
gabe sechan
boh boh