Guía para perplejos: primera vista al código en un nuevo trabajo y... ¡ups!

La anécdota es común, casi una leyenda urbana... cosas que a nadie le pasó pero a todo el mundo le contaron, y reza casi siempre en variaciones del siguiente tema:

"Durante las entrevistas de trabajo todo me pareció perfecto... se habló de implementar las últimas tecnologías y mejores prácticas, de innovación, de una rueda interminable de nuevos y desafiantes productos a implementar.

La gente con la que hablé me pareció de mucha experiencia en el rubro, sin miedo a admitir errores y con ganas de corregirlos a futuro, así que no dudé en cambiar de trabajo.

Ya en el primer día de trabajo, al bajar a detalle, a ver el código... ¡Horror..."

Luego viene una gran lista de WTF's vinculados al desarrollo de software (pueden buscar ejemplos divertidos en The Daily WTF): que tal cosa estaba horriblemente mal, que tal otra era directamente un delirio, que esto no se usa así y que lo otro no se usa asá, o que el jefe esto y el jefe lo otro... La historia en general finaliza con el protagonista huyendo despavorido sin mirar atrás.

Sin exagerar, creo que todos los que entran a un nuevo ambiente de trabajo o a un nuevo proyecto se encuentran con alguna que otra cuestión extraña, no del todo clara, o directamente... digamos... que está mal. Esto es normal, todo equipo tiene sus vicios o errores.

La situación puede ubicarse en una escala que va desde lo divertido a graves errores (siempre desde el punto de vista del ingresante) no ya puntuales, sino de concepto, tanto en el código como en el proceso, pasando por cuestiones que pueden llamarse "de criterio" donde se acepta una visión diferente a la propia sin estar de acuerdo, pero reconociendo sus razones.

La pregunta que propongo es ¿cómo actuar en un caso extremo? Lo que sigue a continuación es lo que yo hice (no "hice correctamente" sino simplemente "hice") e intentaría hacer, aclarando desde el vamos que nunca me vi en una situación así, extrema, donde "está todo mal" y "esta gente no sabe lo que hace y no entiende de razones".

Creo que lo primero y principal es ubicarse y bajarse del caballo, sobre todo si nos integramos a un desarrollo que ya está funcionando.

Es decir, desacelerar, bajar un cambio, no hacer declaraciones rimbombantes, explosivas ni mucho menos agudas o que puedan resultar hirientes para el autor o responsable de lo que se objeta. Creo que podría ser más absoluto: en principio, lo mejor es no decir ni dar a entender absolutamente nada.

¿Por qué? Vamos, reconozcamos que sería poco profesional de nuestra parte entrar a un equipo y declarar, luego de dos o tres días de trabajo "esto está todo mal". ¿Qué análisis pudimos realizar en ese tiempo? ¿Qué tanto pudimos saber en un par de días de las personas que lo hicieron, de cuándo fue y en qué circunstancias?

Así que el segundo paso es, simplemente, recabar información, conocer a las personas que nos rodean y entender cómo llegaron a eso. Todo, absolutamente todo en un desarrollo tiene su razón de ser. Obviamente los orígenes pueden no ser técnicos, pueden ser... digamos "históricos": tienen que ver con una historia que no conocemos y en la cual todavía no escribimos ni una coma.

Esta actitud pone a prueba el respeto al trabajo ajeno: podemos criticar, pero es una falta de respeto hacerlo sin conocer no sólo el problema (que puede que sólo nosotros estemos viendo) sino aunque sea un poco de su historia.

Después de un tiempo (que dependerá también de las urgencias del caso) sin que nos hayan preguntado explícitamente, se puede tantear a ver si una recomendación encuentra algún oído atento. Más que decir "esto está mal", es mejor enfocar las cosas por el lado de "se me ocurrió que podríamos cambiar esto y..."

Pueden pasar dos cosas: que seamos escuchados o que no. En el primer caso es un buen comienzo, independientemente de si "nos hacen caso" o no. Es decir, si alguien escucha y defiende "ese delirio", está bien. Es lo lógico. De a poco, cada vez con más confianza, se puede debatir o incluso pelear. Pero hay que tener en claro que para pelear hay que ganar cierta confianza.

Digresión (está bien escrito, ver RAE): en general no me peleo "mal" con mis compañeros de equipo, pero a veces pasa. Y pasa porque hay cierta confianza que permite pelearse de vez en cuando sin que eso sea catastrófico. Hasta diría que un equipo en el que no hay peleas es algo sospechoso. Si uno tiene una idea, la defiende. Y hay veces en que a uno o a otro se le suelta un tornillo o lo toma a personal (o era personal)... la vida sigue.

Está el tema del tiro por elevación: ¿qué pasa si sentimos que el problema está en una persona en particular? Puede ser un compañero, un líder de proyecto, un analista, un gestor, lo que sea. ¿Hablamos con su superior? Puede ser, nunca sin haber intentado por todos los medios debatir con él primero, y teniendo en cuenta que puede "salir mal", por lo que se vuelve más importante que nunca tener un planteo coherente, no agresivo, y una propuesta de solución.

Ahora, ¿qué pasa si realmente no vemos posibilidades de cambiar las cosas, o sentimos que no queremos hacer semejante esfuerzo? Bueno, nada. Alejarse. Buscar otro trabajo, cumpliendo lo mejor posible con la tarea que se nos asigna mientras tanto. Sin escándalos, y sobre todo, sin "tirar basura" a los que quedan para irse con un portazo, eso sólo habla mal de uno mismo.

Aclaro otra vez: que no conozco la verdad revelada, y que lo que creo o recomiendo surge más de mis errores que de mis aciertos. En el papel (o la pantalla) es todo muy fácil, pero la vida real es otra cosa. Supongo que lo único que se puede hacer en este tipo de situaciones muy complicadas es hacer el mayor esfuerzo posible.