En los últimos meses he estado involucrado en varios proyectos de revisión de código y aplicaciones. Este tipo de proeyctos me resultan muy entretenidos por el análisis que se debe realizar la necesidad de aplicar ingeniería reversa no solo al código sino al razonamiento asociado al mismo, pero ese no es el punto de este post.
Como parte de los proyectos pude trabajar con muchas personas distintas en un mismo tipo de entorno y esto me hizo recuerdo de las grandes diferencias entre tes términos que muchas veces son mezclados por razones erróneas, el desarrollador, el consultor y el resolutor de problemas.
En uno de los proyectos que hicimos trabajamos con un muy buen desarrollador un persona queera muy buena dise;ando y escribiendo aplicaciones, un amplio manejo de patrones, TDD, herramientas de ciclo de vida, en fin una persona que sería invaluable en cualquier equipo de desarrollo de aplicaciones o productos. Sin embargo, esta persona no tenía los skills para ser un buen consultor o revisor. Como consultor le faltaba la capacidad de presentar y exponer sus resultados de administrar los tiempos de avance y manejar la presión y riesgos de una situación complicada.
Ahora en otro proyecto teníamos un buen consultor. Alguien que podía integrarse en un equipo rapidamente podía transmitir sus hallazgos, medir el impacto de cambios y desarrollos más allá del código. Analizar riesgos y oportunidades de manero coordinada, en fin un buen consultor y además era un buen desarrollador pero aún así no era un buen resolutor ¿porque? porque no supo desenvolverse en un escenario que no era el suyo controlado. Es decir al ver código de otras personas tuvo problemas en entenderlo, asimilarlo y simplemente se perdió en el entorno donde alguien más con otros criterios desarrollo la solución y terminó frustrandose.
También en estos proyectos tuvimos la suerte de contar con buenos revisores gente que no solo supo entender rapidamente lo que el código hacía sino ademas el razonamiento detrás de la escritura de ese código y las potenciales áreas de falla. Estas personas además supieron construirse un entorno de pruebas, confirmar sus hipótesis de áreas de mejora, pudieron emitir recomendaciones e implementarlas. En fin este perfil se siente mucho más cómodo en entornos desconocidos y donde la documentación e información es escasa y no clara
Es importante que cada uno sepa cual de estos perfiles le sienta mejor para poder explotarlo al máximo
