Juanjo Coello

Software Developer & Perpetual Wannabe
I tweet stuff at @jjcoellov

La Informática Académica y la Profesional

Uno de los motivos del abandono del blog ha sido - a parte de la apatía crónica que se ha convertido en seña característica de mi personalidad - la falta de tiempo con el que cuento para dedicarle a mis hobbies (esta bitácora entra por supuesto en esa categoría). Y dicha carencia se ha debido principalmente a mi actual dual-boot personal: el estudio y el trabajo.

En junio del año pasado acabé prácticamente la Ingeniería Técnica en Informática (con el examen de una asignatura pendiente para septiembre), y en julio empecé como becario en prácticas en una empresa de Informática como programador. El diciembre pasado pasé a formar parte de la plantilla, en donde continuo y donde espero que por un largo período de tiempo. En momentos de introspección, tales como a la espera de que finalice la compilación del proyecto u oyendo la aburrida diatriba de los políticos por la tele, he reflexionado sobre los grandes cambios que ha tenido mi vida en este medio año, tanto en labores, como en prioridades, responsabilidades, etc.

Siempre me habían dicho que the world outside these walls era totalmente diferente al controlado entorno de la Facultad. Que lo hacía mover otras directrices, otros intereses e incluso que giraba a otra cadencia. Y habiendo experimentado dichas diferencias, puedo decir que son ciertas.
Supongo que todo depende también del trabajo que te haya tocado y de la actitud/aptitud que tengas para enfrentarte a él, pero en mi caso particular las diferencias han sido notables, y solo una buena adaptación a los cambios algo exabruptos puede hacerte desempeñar tus obligaciones en ambos mundos de una forma relativamente eficaz.

Como es mi primer empleo en el sector (la hostelería no entra en el sector, ¿no?) y particularmente en el Desarrollo de Software, no conozco muy bien si esto es lo que suele ocurrir, pero algunos de los aspectos que difieren y que me han llamado la atención están:

- La gran escala. Imagínense que juegan en una caja de arena de cualquier parque de ciudad medianamente grande. Estamos un período de tiempo limitado en la caja, aprendiendo un cierto número de nociones, herramientas o metodologías dentro de ella. Un día decidimos abandonarla. Y terminamos en medio del parque, lejos del mundo conocido y controlado. Otros chiquillos nos habían hablado de la zona y de lo que ahí habita, pero ahora lo vivimos en nuestras carnes. El parque es enorme en comparación a nuestra caja de arena. No tiene los puntos de referencia que controlábamos ni la extensión con la que estábamos acostumbrados a convivir. Empezamos a sentir cierto abatimiento y estupefacción. No sé si estoy preparado para estar aquí. Todo esto me viene grande. Estoy perdido. No sé si valgo para esto. Pues bien, para mi la caja de arena es la Universidad, y el parque el Mundo Profesional, un mundo mucho más vasto y extenso al que tendremos que adaptarnos. Creo que la clave es la paciencia. Con el tiempo nos volvemos a acostumbrar a las nuevas medidas, aprendemos las nuevas referencias y nos volvemos a sentir cómodos. Hasta que nos toque movernos a un parque más grande. Y volvamos a empezar.

- Herramientas específicas. Sigamos con el símil de la caja de arena. Dentro de ellas contamos con un cierto número de accesorios y cacharros. No hemos tenido tiempo de conocerlas en profundidad, pero tenemos las nociones básicas para utilizarlas: con una pala cavamos y con un cubo recogemos arena. Sabemos que hay muchas marcas y modelos de cubos, que unos son mejores y otros peores, unos más baratos y otros más caros, y algunos más fáciles de entender y otros complicados como un misil tierra-aire. Bien, al salir al parque nos dicen que hemos de usar el cacharro A, versión X, de proporciones NxH. Se puede usar como J y K, pero que nos interesa adaptarlo para trabajar como P. Casi nada. Nos dejaron out por la vía del ponche. Nos suena de que existe la herramienta A mientras buscabas información sobre B, pero hasta ahí. Nos preguntamos por qué demonios me enseñaron a usar C con la especificación Z y nos sentimos estafados. Nos dedicamos a aprender A versión X, aunque a mitad de camino ha salido X+1 y X dejará de recibir soporte, lo que obliga a averiguar qué cambios ha habido respecto a X, cuándo volverán a implementar alguna funcionalidad que había y que han desactivado temporalmente. De repente, le encuentras uso a esos conceptos que siempre han estado ahí y siempre se han ignorado, que se llaman Changes y Roadmap. Pero por otra parte, aparece un nuevo concepto que muy pocas veces nos habrán afectado en nuestro playground:

- Los bugs. El martillo en la caja de arena era espectacular. Hacía su función con precisión (siempre que se usara adecuadamente) y además venía con un extrae clavos en la parte posterior que nunca habíamos necesitado, pero que estaba ahí por si algún día era necesario echar mano de él. Bien, afuera, en el parque, necesitamos usar dicha funcionalidad. “Menos mal que tenemos el martillo”. Pues bien, al intentar quitar los clavos, éstos se rompen. No por ineptitud nuestra sino porque el martillo tiene un defecto en la manera en que fue diseñado, de tal forma que la fuerza física se aplica en los sectores del clavo que lo hacen más endeble, y lo rompe. Llamas al fabricante y se lo comentas. Tiene razón, en dos meses lo solucionamos, en la próxima release del producto. WHAT? El proyecto de casita de madera es para el mes que viene. En este caso no hay mucho problema. Hay más martillos en el mercado. Pero, ¿y si no los hubiera?, o peor, ¿y si el cliente no quiere usar otro martillo?. Al final se termina sacando los clavos con los dientes, y pasa lo que pasa, todos desdentados a los 30. Normalmente los bugs no aparecen en la funcionalidad principal del programa, eso que normalmente estamos acostumbrados a usar en la facultad. Suelen estar escondidos en las funcionalidades más específicas y que se necesitan utilizar en los proyectos profesionales. Te obliga a ser imaginativo en las alternativas de implementación, y muchas veces repercute (para mal) en la eficiencia del producto.

- Trabajo en Grupo. En la caja de madera casi siempre trabajábamos solos. ¿Cómo se puede saber si todos sabemos construir un castillo de arena si no lo hacemos solos? Algunas veces nos ponían en grupos para llevar a cabo proyectos más amplios, intentos tímidos de lograr una interacción grupal. Pues bien, en el parque, prácticamente todo se hace en grupos. La falta de costumbre crea problemas al principio. Carencia de coordinación y por tanto ineficacia. Maaal. Con el tiempo se empiezan a lograr (se deben lograr) nociones de trabajo en grupo que deberían haberse potenciado en la caja de arena. La comunicación entre compañeros, la negociación de puntos de vista y la organización del grupo, de tal forma que las labores sean lo suficientemente independientes para llevarse a cabo individualmente, pero no tanto como para que el acoplamiento posterior sea abordable. Es importante entender la interdependencia que existe, y la necesidad de adaptarse a ella para lograr llevar a cabo el trabajo en armonía (cosa que a veces no es fácil conseguir).

- Documentación. Prácticamente todos los informáticos vemos la documentación como un castigo, que vamos postergando hasta que al final a-) No se hace b-) Se hace rápido y mal. Pues bien, después de sufrir una documentación mal hecha y peor, desfasada, he valorado la importancia de no solo los comentarios en el código, sino de unos buenos diagramas de casos de usos actualizados. Particularmente sobre estos últimos, su realización en la asignatura de Ingeniería del Software resultaban tediosos. No entendíamos bien por qué había que escribir los siete escenarios básicos del caso de estudio, si eran eso, básicos. A nadie se le iba a olvidar qué hacían. Pues bien, para entender su importancia capital hay que plantearse la sensación que se tiene al llegar a un proyecto llamado “Soporte para la tramitación electrónica de expedientes de regulación administrativa” (por poner un ejemplo), con dos años de vida y en el que acabas de entrar como desarrollador. Tiene alrededor de 12 casos de uso básicos (¿básicos para quién?), ya implementados, y que hay que probar. ¿Cómo, si no hay escrito en ningún lugar lo que deben hacer, puedes desempeñar la tarea sin molestar a tus compañeros que tienen sus propias obligaciones? No se puede. Y te sientes inútil (quizás siempre lo has sido, pero ahora la sensación en más nítida) Por eso, documenta, no pensando en hoy, sino pensando en el año que viene cuando ni te acuerdes por qué carallo eso se hace así y no justo al revés.

- Código muerto. Esta ha sido la mayor sorpresa de todas. Un compañero los ha llamado “Métodos Placebo”. Interminables líneas de código que no hacen nada. Pero nada. Métodos obsoletos, sin limpiar porque no ha habido tiempo, porque se ha cambiado el grupo de desarrollo seis veces, porque se cambiaron los requisitos a mitad de implementación y se intentó recuperar partes de código que al final eran irrecuperables. Creadores de ruido. Métodos reutilizados, pero mal reutilizados. Calzados a la fuerza. O peor, funciones directamente mal programadas. Bucles iterativos de complejidad n cuadrado o n cubo que retornan null, que no modifican ningún atributo y que te hacen perder completamente la fe en los demás pica-códigos. Très déprimant.

Como se ve, hay cosas que considero buenas y considero malas en ambos mundos. Hay muchos más detalles y características que se me has escapado explicar, pero la diferencia entre un mundo y otro creo que ha quedado medianamente clara. Otras reflexiones que me gustaría añadir, sin tener muy claro cómo clasificarlas, serían:

- El tiempo. Obviamente la carencia de tiempo para el estudio implica adquirir un nivel mayor de organización y planificación personal (en otro post explicaré la metodología que estoy intentando llevar a cabo con más o menos acierto). En necesario priorizar las acciones que se deben llevar a cabo, y como suele decirse, evitar que lo urgente nos impida ver lo importante.

- La experiencia. Trabajar te abre la mente sobre cuestiones y resoluciones de conflictos que en la Universidad no ocurren y que por tanto pasan desapercibidos para nosotros. Quizás lo más importante sea todas lo relacionado con el trabajo en grupo y la necesaria comunicación que ha de existir entre todos los miembros. Son probablemente los hábitos más importantes que he aprendido.
- Asimilación de Contenidos. Es interesante poder relacionar contenidos aprendidos en clase con problemas del mundo real. Se supone que todo lo aprendido en la Universidad es útil, cuando en realidad gran parte no es del todo cierto. Pues bien, cuando sí lo es, resulta bastante gratificante poner en práctica lo que ya sabemos para resolver esas cuestiones.

- Metodología de enseñanza. Se aprende a valorar mucho las clases participativas, la aportación de los estudiantes en el desarrollo de las clases, no solo para no dormirse en las mismas, sino porque nos ayudan a elaborar criterios y puntos de vistas propios que son necesarios a la hora de exponer ideas en reuniones de trabajo y a la hora de abordar un problema. Las clases magistrales (esas donde el profesor lo sabe todo y simplemente se dedica a recitar un sarta de ideas, y donde no se preocupa por comprobar si se entendió) no solo son perjudiciales para el aprendizaje de lo que se enseña, sino que afecta en nuestra capacidad de crítica, inferencia de conclusiones y nuestras habilidades para exponer nuestras convicciones sobre un problema.

- Contenido adicional o background. Casi tan importante como lo que se enseña en clases es todo el conocimiento relacionado que aprendemos por nuestra cuenta. Esas herramientas que no nos han ordenado utilizar pero que nosotros hemos aprendido porque nos resultaba interesante y nos hacía más fácil llevar a cabo esas prácticas que sí teníamos que entregar. Esos libros que hemos leído sin estar totalmente relacionados con la materia impartida, las conferencias en que había 6 personas incluyendo al ponente y al conserje, o los continuos ensayos de prueba - error. En general, todo lo que hemos aprendido que no se encuentra en ningún plan de estudio. Esa capacidad de trabajar por nuestra cuenta viene muy bien a la hora de resolver problemas en el trabajo, y de hallar alternativas muchas veces desconocidas.

Se me ha hecho bastante largo el post, pero no me gustaría acabar sin dar un par de consejos que ya he citado antes pero con los que deseo concluir, y que sirvan para aquellas personas que tienen pensado trabajar y estudiar al mismo tiemp. Si desean obtener cierta cotas de éxito en ambos campos deben tener en muy en cuenta: organización del tiempo, priorización de objetivos, mantener en contextos separados las clases y el estudio (los deberes de clase, en el tiempo de clases, de igual forma al trabajo) y no rendirse. Cuando las cosas se tornan duras, parar un momento., desconectar, y volver a empezar. Los momentos justos después de haber detenido la maquinara pensante suelen darnos un enfoque nuevo para encarar de manera diferente ese problema que no hallamos solucionar.

Suficiente. Me voy a comer, que el hambre no perdona.