Como programadores hay ciertas conductas que tenemos que evitar si no queremos perder nuestro puesto de trabajo en el acto. Muchas de las ideas que se comentarán a continuación pueden ser causa de despido en muchos otros sectores pero como este blog es para desarrolladores de software lo analizamos desde esa perspectiva.
En las empresas de desarrollo la confianza es un valor clave porque cualquier acto de deslealtad por parte del desarrollador puede suponer un daño irreparable para la empresa: filtraciones del código fuente, plagios, difundir información confidencial, etc...
En la mayoría de los casos podemos concluir que las causas de despido fulminante se pueden resumir en las siguientes categorías:
- Negligencia grave, como eliminar "sin querer" una gran cantidad de datos.
- Incompetencia,
- La falsificación, la mentira, la tergiversación y cualquier otra acción que genere desconfianza.
- Intenciones maliciosas como intentar apropiarse o vender a otra empresa código fuente cerrado con derechos de autor y relacionados.
- Comportamientos ilegales o poco profesionales, como desvelar información confidencial o datos protegidos por la ley.
- Vanagloriarse todo el tiempo de los logros personales, queriendo demostrar todo el rato ser un programador x10, que también mina la relación personal con compañeros y superiores jerárquicos ya que puede herir muchos egos.
Habiendo enumerado de forma resumida las causas más comunes que pueden desembocar en despidos "express", veremos ahora algunos casos más tangibles para entender mejor dicha casuística.
Apropiarse de código fuente cerrado
Si tu empresa simplemente te despide por apropiarte de información confidencial y revelarla a terceros, tendrás suerte. Lo normal es que te caiga una demanda penal.
Esto es algo por lo que no solo se te despide ipso facto, sino que te pueden detener, interrogar y ser acusado por sustraer información confidencial.
Se han dado casos que no son muy conocidos como el de un desarrollador que trabajaba para una empresa de programación y que programaba código dentro del ámbito de la empresa que bajo ningún caso podía programarse desde fuera. Su software periódicamente informaba sobre su estado enviando un email a un servidor que recolectaba información sobre el estado del mismo. Tanto el software que enviaba los emails como el servidor que recibía los emails se suponían que estaban en la intranet corporativa. Un día su servidor empezó a recibir emails desde fuera de la empresa. Otro empleado había sustraído una copia del código y lo estaba ejecutando desde fuera del ámbito de la empresa. Sabían perfectamente quién lo había robado, y a dónde lo había llevado: los emails fueron enviados desde nombre.del.ladró[email protected] ¡Una lumbrera!
La nueva empresa fue informada sobre el suceso, y al responsable de la sustracción lo despidieron. Se llegó a pleitear y hubo condena.
La moraleja de la historia es: antes de robar código, párate a estudiarlo y a entenderlo antes de ejecutarlo. O mejor: no lo robes ;-)
Incompetencia y tergiversación
Un CEO de una empresa de desarrollo comenta que solo ha despedido a sus empleados programadores por dos razones:
-
Incompetencia, que se manifiesta cuando un desarrollador exagera sobre sus destrezas en su CV. Si dices que llevas tres años programando, tu código debe reflejarlo. Si dices que has hecho una implementación de Apache Hadoop, debes ser capaz de hablar sobre algunas de las buenas prácticas a la hora de hacerlo. Este tipo de cosas...
-
Tergiversación, que se da cuando un entregable no está a la altura de lo esperado o cuando un código no hace ni por asomo lo que tiene que hacer. Por ejemplo, un desarrollador comenta que casi ha terminado con una tarea y prolonga esa historia durante un par de sprints más. Cuando revisas el trabajo ves que el código es horrible. O lo que es peor, ves un código que solo ha requerido una milésima parte del esfuerzo que el desarrollador afirma que le ha costado hacer.
Este CEO luego comenta que cree en las segundas oportunidades, así que no despedía a nadie fulminantemente por este tipo de asuntos. Por un lado es una forma de exigirle a un empleado lo que ha prometido, tipo: "oye, has dicho que sabías hacer esto, aprende a hacerlo y rápido." Y por otro lado: "demuéstrame que eres capaz de hacer esto que dices."
Si estas situaciones no terminan en una mejora en el rendimiento y las actitudes son reiteradas en el tiempo, evidentemente termina en despido.
Saltarse órdenes directas
Una causa muy común de despidos es saltarse las órdenes específicamente indicadas por un superior.
Un ejemplo es la historia que relata un ingeniero informático. Cuenta que trabajaba con un grupo extraordinario de 20 ingenieros senior a finales de los años 90, cuando cualquier fallo en el build nocturno significaba llamar a todos los programadores implicados en la creación del código, a las 9:30 de la noche. Tenían que solucionar el problema tras una breve y colérica ráfaga de intercambio de emails. De esta forma, todo sea dicho, conseguían hacer un equipo de ingenieros orientado a hacer las cosas bien... mediante la presión de grupo.
Comenta que uno de los ingenieros hacía que el build se rompiese en varias ocasiones, y a medida que se acercaban a la fecha de lanzamiento de la versión trimestral, se le pidió expresamente que no registrara ningún cambio. Poco antes de la salida de la versión -se veía venir- registró unas modificaciones que hicieron que se rompiera el build. Al día siguiente le mostraron la puerta. Hubo aplausos.
Aquí la moraleja es no desobedecer las órdenes de tus superiores jerárquicos. Sobre todo si dichas decisiones están alineadas con las expectativas del equipo.
Otro desarrollador cuenta que trabajaba en una empresa de videojuegos y que uno de los equipos de trabajo estaba muy centrado en un juego con mucha expectación para la Nintendo DS. Entre ellos había un joven programador japonés un poco cándido que se sentía muy emocionado por estar trabajando en tan ilustre videojuego. Tal era su alteración que hizo un par de capturas de pantalla del videojuego y se la envió a un amigo para alardear.
Los pantallazos correspondían a una versión muy preliminar que estaba aún por definirse. Naturalmente, acabaron apareciendo en varios blogs de videojuegos, no solo en japoneses sino mundiales. La empresa rastreó la filtración hasta el inocente programador japonés y le despidieron de inmediato.
Según el protagonista era un tipo majo, y fue un error estúpido y muy ingenuo, pero la verdad es que no da mucha pena. Un videojuego es una inversión titánica y lleva muchos años desarrollarlo con un equipo enorme. Cuando muestras un juego antes de que esté terminado, el público da por hecho de que esa será la verdadera calidad del juego como producto terminado. Cualquier cosa que no esté bien pulida puede llegar a causar un verdadero terremoto entre los unos fans furibundos. Las casas de videojuegos tienen que tener mucho cuidado a la hora de sacar un juego, porque puede ser un éxito o un fracaso al antojo de un Internet inflamable. Con que un solo influencer dictamine que algo no le gusta, o extienda un rumor dañino puede arruinar totalmente un proyecto.
Mentir
Por último, recogemos la anécdota de un trabajador de una empresa de tecnologías de la información, que a pesar de ser un trabajador absolutamente incompetente, consiguió que lo despidieran únicamente tras imprimir anime "subidito de tono" en transparencias en una impresora de color en horas de trabajo. Pero no lo despidieron por esto.
Usó transparencias que no estaban diseñadas para impresoras láser, que se derritieron y terminaron estropeando una impresora muy, muy cara de forma irreparable. Pero no lo despidieron por esto.
Decidió abrir la impresora, la desmontó, e infringió las condiciones de garantía de la misma. Pero no le despidieron por esto.
Lo despidieron porque lo negó todo. Mintió. Así de fácil. ;-)
Nota: las historias de este artículo son un compendio de algunas de las respuestas de este hilo de Quora que nos han parecido más ilustrativas.
Fecha de publicación: