Existe un raza de programador que reconocerás fácilmente. Tienden a ser inconformistas, caen en depresión cuando terminan un proyecto pensando que lo han hecho fatal y reconocen abiertamente que, si pudiesen volver atrás en una máquina del tiempo, usarían otro enfoque totalmente diferente, aplicando una metodología que descubrieron a mitades o final del desarrollo, o con tecnologías diferentes y herramientas más avanzadas que no conocía al comienzo de la tarea.
No es fácil convivir en un proyecto con uno de estos personajes, especialmente cuando es uno mismo. Es un defecto que hace rozar la bipolaridad a la persona que lo lleva encima, pudiendo pasar de la más absoluta euforia, cuando todo parece estar en la frikidirección correcta, a la depresión por haber encontrado un error en el planteamiento a las muchas semanas de haber comenzado el proyecto. Hoy toca autoanálisis en voz alta.
No seas un bicho raro: habla con tu equipo
Aunque seas el que más controla en todo esto, si quieres que tu equipo cada vez sea mejor consensúa y explica tus opiniones con ellos. Es posible que te hayas dejado aspectos de lado y ellos sean capaces de verlo. De hecho lo verán porque tu mente se ha acostumbrado a pensar en aspectos más específicos y cuantos más pensando, mejor.
Aparte de los aspectos prácticos al equipo le gusta participar de los éxitos igual que le tocará sufrir de los fracasos y errores, pero todo esto es parte del aprendizaje, tanto tuyo como de ellos. Comparte y enriquécete con todos, usa tu pizarra, fomenta que todos salgan a explicar sus propuestas y deja de ser ese “wannabe” de persona infalible.
Los experimentos, con gaseosa
¿Cuántos frameworks nuevos se publican cada semana? Aguanta a tu “oscuro pasajero” y pruébalos en casa, con tus pequeños desarrollos. Aquí podríamos aplicar el sabio refrán de
más vale lo malo conocido que lo bueno por conocer
Claro está que, si hemos usado una tecnología, framework o lo que sea y nos ha ido mal porque está claro que el producto es malo no habrá más remedio que cambiarlo pero no olvides que, aunque lo cambies para el siguiente desarrollo, tendrás que seguir manteniendo el anterior por muy mala que haya sido la experiencia. Mejor encontrar un producto medianamente bueno y especializarse para sacar el máximo rendimiento.
Tampoco abuses de construir tus propias herramientas que, por muy frikis y chulas que sean, ya casi todo está inventado. Si estás en un momento de I+D adelante y hazlas pero ,si tu objetivo principal es sacar proyectos adelante para poner en producción en el menor tiempo posible y con la mayor fiabilidad que se pueda, confía en las herramientas de terceros.
Abusa del análisis y usa TDD
Analizar a conciencia los proyectos te llevará a tener una visión clara de las necesidades de los mismos y evitarás cometer de nuevo los errores si te vuelves a creer Indiana Coder y vuelves a pensar que estás haciendo un sistema de control de cohetes espaciales en vez de una aplicación de gestión comercial para web.
Y, como estarás deseando hincar el diente y meter manos a la obra, la mejor manera de ponerse es no ponerse. Antes de picar una sola línea de código más te valdrá preparar los tests unitarios que te darán la foto real del plan de ruta de tu proyecto, al menos tu cerebro irá trabajando con los conceptos con los que se siente cómodo: el código como representación de ideas y funcionalidades. Aunque este sistema no es el mejor posiblemente es mucho mejor que aquellos donde la frustración y la rebeldía conseguía ganar una y otra vez sin terminar de despejar de nubes el horizonte de los proyectos venideros.
