Acerca del Ego-istmo
Una de las cosas que más echo en falta en los técnicos es el egoísmo. Se que es una frase fácil de malinterpretar, por eso quiero explicar a qué me refiero.
En general, en el mundo técnico he tenido la suerte de trabajar por norma con personas que se dejan la piel por ayudar a sus compañeros. Siempre he defendido que todos somos muy majos para tomar unas cañas y salir de copas (alguno incluso pagamos una ronda), pero a los compañeros se les conoce bajo presión, cuando las cosas van mal, no funciona nada, empiezan a llover las hostias y entonces se ve quién se arruga y quién tiene lo que tiene que tener.

Da igual que lo llames Scrum o Melé, sigue siendo una metodología ágil (Imagen de John_Scone)
También me parece fundamental, como parte del valor que aporta un profesional a su empresa, la actitud de dejar lo que se está haciendo para echarle una mano a un compañero que necesita ayuda. En MediaNet trabajo con esa clase de personas, igual que antes lo hacía en SATEC.
No entiendo nada, Guardiola, estás hablando de compañerismo y generosidad en un post que trata sobre el gen del programador egoísta; definitivamente se te ha ido la pinza; adiós.
Bueno, es que no me refiero a ese tipo de egoísmo. Me refiero al egoísmo que tiene que ver con hacer cosas que no me gustan, pero que tengo que hacer porque son necesarias para mí mismo. Y del egoísmo que tiene que ver con hacer cosas por las que no me pagan o para las que (creo que) no tengo tiempo, pero que tengo que hacer porque me gustan y si no las hago yo, las harán otros en mi lugar. Me refiero al egoísmo que viene del ego, del yo, de aquello que tengo que hacer sea como sea y cueste lo que cueste porque me acerca a mis objetivos. (Otra vez se repite la frase, acercarse a los objetivos de uno. Es la segunda que vez que la uso en el blog. No será la última.)
El gen del programador egoísta, o mejor dicho, el poco frecuente gen del programador egoísta, se materializa claramente como recesivo en dos situaciones que seguro que todos hemos vivido alguna vez; la primera de ellas la trataré en este post (y la otra la añado a la larga lista de post pendientes)
El gen del programador complaciente
El gen del programador complaciente se manifiesta dominante frente al egoísta en todo lo que tiene que ver con pruebas e incidencias.
Los proyectos con presupuestos cerrados suelen ir bien hasta la semana antes del paso a producción, da igual que se usen metodologías ágiles o no. Todo va bien, las historias de usuario se completan, se va gestionando el cambio, a los usuarios todo les parece bien, y de repente un día alguien (generalmente el cliente) empieza a hacer pruebas y hay una estampida de incidencias que salen como setas. Por todas partes. Hasta el punto de que empiezan a tambalearse los cimientos, se comprueba con horror que el sistema está cogido con alfileres y no funciona nada.

Pues en mi entorno local funcionaba (Imagen de Drakegoodman)
Cada vez que un desarrollador dice frases como «pues cuando lo probé iba bien» o «en mi local funciona«, Dios mata un gatito. Si dice cosas como «es por un micro-corte de red que hace que se pierda la conexión con la base de datos«, Dios extingue una especie tropical (además de los habituales gatitos).
Si hacemos una encuesta entre 10 personas cualquiera que se ganen la vida desarrollando software, llegaremos a la conclusión de que lo más apropiado es que el aseguramiento de calidad de un sistema lo haga alguien diferente del que lo programó, por varios motivos, entre los que destacan:
- La persona que lo desarrolla sabe lo que se supone que tiene que hacer el sistema, y cuando prueba tiende a comprobar que hace exactamente aquello que le pidieron
- La persona que lo desarrolla está contaminada porque sabe cómo funciona la aplicación y por tanto, los pasos que tiene que dar para probarla
- Hay mucho que desarrollar, y no da tiempo a probar (obviamente, porque el proyecto estaba mal vendido, ya hablaremos en otro post sobre eso)
- Desarrollar es como criar un hijo, todos los padres pensamos que nuestro chico es el más listo de la clase, todos los inputs que recibimos refuerzan esa sensación y nos cuesta ver lo contrario por nosotros mismos (en realidad hablo de oídas, porque mi hijo es el más listo de la clase)
Y aunque estoy a favor de que haya departamentos de QA que de manera independiente al desarrollo validen que esté libre de errores (o en su caso los detecten), lo ideal sería que los entregables que reciben estén como los chorros del oro; que se pudiera comer sopitas en ellos.
¿Y por qué no es así? Pues básicamente porque los cuatro motivos de antes se resumen en que el programador es auto-complaciente. Enseguida se convence a sí mismo de que todo está bien hecho, de que ha hecho lo que tenía que hacer, y si algo falla, es por culpa de otro que no hizo su trabajo bien, o no le pasó la información que necesitaba cuando la necesitaba, o que no le explicó detalladamente algo, o que no abrió un puerto en el firewall, o que le cambió una especificación dos días antes de terminarla… He llegado a oir que el error era culpa de la persona que hizo las pruebas, que no prueba bien el sistema y falla. #amazing
A lo que yo digo, vale, ¿y qué? Has hecho un desarrollo que tiene más agujeros que Bob Esponja así que da igual que le hayas echado cientos de hora de tu vida, la mala noticia es que no han sido suficientes porque todavía no has terminado: ahora lo tienes que arreglar.

¿A qué te refieres con eso de Plan de Pruebas, Bob? (Imagen de gspidermac)
La auto-complacencia es uno de los peores defectos que puede tener un profesional, pero se acentúa en el caso del programador. Hay dos situaciones en la que el egoísmo debe ser la clave para sobreponerse ante la auto-complacencia, sobre todo por los devastadores efectos que tiene sobre uno mismo.
El problema de la mochila
Todos los que hemos programado conocemos el problema de la mochila; hay que hacer un algoritmo que permite tomar objetos de un determinado volumen y valor para llenPUES NO. Ese no es el problema de la mochila.
Cuando uno entra a una empresa y empieza a programar, va pasando por proyectos. Algunos serán más largos, otros más cortos; unos serán un reto, otros no tanto, y todos en general formarán parte de su trayectoria profesional. De cualquiera de ellos podrá recibir un día un correo electrónico (o una llamada, según la gravedad) indicándole que tiene que dejar lo que está haciendo porque tiene que resolver una incidencia en uno de los proyectos por los que ha pasado.

Todavía son becarios, y ya tienen sus mochilitas (Imagen de ewar woowar)
El problema de la mochila es una maldición intrínseca de las personas que se dedican al software: cuanto más avanzan en una empresa, mayor es el peso que llevan en su mochila, más posibles incidencias pueden surgir; y por tanto estadísticamente más veces va a tener que dejar de hacer algo, porque la única persona que puede solucionar un problema con garantías suele ser quién lo resolvió la primera vez.
Primera Ley Natural del Programador Egoísta. Las cosas no terminan hasta que terminan. Si quieres salir cum laude de un proyecto encárgate de que todo lo que desarrolles funcione; y cuando falle, arréglalo lo mejor posible para que puedas seguir adelante hacia tus objetivos.
La conclusión es que cuanto más riguroso seas contigo mismo y con tu desarrollo; es decir, cuanto menos auto-complaciente seas, menos peso llevarás en tu mochila.
Sísifo Consulting
La segunda derivada de la auto-complacencia en el desarrollo es el temido Síndrome del Proyecto Sísifo. Como todos sabemos, Sísifo era un rey que quería vivir eternamente, engañó a los dioses mientras pudo hasta que le trincaron, momento en el que le condenaron a subir una piedra hasta lo alto de un monte. Lo que pasa es que al llegar a la cima, volvía a caer hasta la base; y así por toda la Eternidad.

Ánimo, otro empujoncito y vaciamos el Jira (Imagen de ChuckSchultz)
En tecnología, llamamos Proyecto Sísifo a ese proyecto en el que salen errores como cucarachas, hasta debajo de las piedras, de forma que se establece un círculo vicioso que es difícil romper: no se sale a producción porque hay errores; al no cumplir los objetivos el cliente dice que ya que estás le haces unos cambios; por la sensación de falta de rigor en el desarrollo e inclumplimiento se termina por perder la capacidad negociadora; con lo que hay que asumir los cambios; por hacerlos deprisa y corriendo para no palmar pasta surgen nuevos errores; y así sucesivamente. Por toda la Eternidad.
Segunda Ley Natural del Programador Egoísta. Si detectas que esto se va a convertir en un Proyecto Sísifo recuerda la Primera Ley Natural del Programador Egoísta.
Que yo sepa, sólo hay 3 maneras de salir del Proyecto Sísifo:
- Abandonar, como las ratas y los cobardes. Opción descartada, salvo para las ratas y los cobardes.
- Salir con los pies por delante. El fracaso no es una opción.
- Pensar en uno mismo, ponerse las pilas y hacer bien las cosas, porque nadie más lo hará por ti. El egoísmo es la única salida.
La conclusión es que cuanto más riguroso seas contigo mismo y con tu desarrollo; es decir, cuanto menos auto-complaciente seas, más probabilidades de que el resultado de tu trabajo sea un éxito para tu cliente, para tu empresa, y por tanto, para ti mismo.
Se egoísta: piensa en tí mismo. Ojalá cada vez hubiera más gente convencida de que la auto-complacencia es uno de los mayores enemigos de la realización personal.
Tercera Ley Natural del Programador Egoísta: Si no te das una patada en el culo de vez en cuando, alguien lo hará por ti. Y te va a doler más.
Otro día escribiré sobre otra situación en la que las personas sacrifican aquello que les acerca a su objetivos. Mientras tanto, puedes aprovechar la sección de comentarios para decirme si eres o no un profesional auto-complaciente, si llevas mucho peso en tu mochila o si estás a punto de que la piedra llegue a la cima de la montaña.
Me gusta esto:
Me gusta Cargando...