Sunday, June 19, 2016

Razón vs experiencia vs intuiciones

Al entrevistar candidatos para posiciones dentro de mi grupo profesional en arquitectura y diseño de software busco un rasgo determinante: sus contribuciones a proyectos de código abierto (public open source projects). El estilo de colaboración, patrones y técnicas de diseño e integración a ese tipo de proyectos, para mí, es evidencia clave para saber a quién estoy entrevistando, más allá de palabras impresas en su currículum o mucho más allá de número de “certificaciones”.

Yo dejo muy poco a mi mera intuición pues no me ha resultado muy confiable. No se me da eso de percibir de manera inmediata la realidad detrás de las apariencias. Para lograr un juicio profesional yo necesito primero averiguar los hechos de la experiencia y también examinar los argumentos de un caso. De hecho, al entrevistar candidatos acostumbro pedirles que realicemos una sesión conjunta de diseño de software directamente en una computadora y con algún compilador, por más o menos 30 minutos. Juntos colaborando sobre un problema de diseño y una aproximación a una posible solución. Es como una sesión «pair programming».

Sí, la mera intuición juega algún papel, pero explícitamente evito que sea determinante. Mi razón principal está en la rendición de cuentas pues hay mucho en juego: la calidad del software y su impacto en la satisfacción de clientes y usuarios de un proyecto de desarrollo no es algo que, de ser posible, deje en manos de una corazonada —por supuesto, en el caso de «mera intuición» como eso, como un presentimiento. Hay, claro, otro tipo de intuición: la intuición profesional, pero esa es muy distinta de una corazonada o presentimiento. La intuición profesional suele estar basada en muchos casos variados de ejercicio tanto racional como experimental.

Precisamente eso, una mezcla particular entre el uso del raciocinio y de la experimentación, es lo que intento identificar durante la sesión cooperativa de diseño y programación que hago durante la entrevista. Dejo en claro que no intento medir cuánto sabe el candidato, sino su disposición para el trabajo intelectual cooperativo. Crear software no trivial es un esfuerzo intelectual con mejores resultados –en mi experiencia– si se hace cooperativamente. Por ejemplo, el candidato necesita no sólo disposición para aprender de otros, sino también para enseñarles efectivamente; de ahí que si aprendí un par de cosas del candidato durante esa sesión inicial, entonces definitivamente llamó mi atención.

Entonces, digamos que lo que me dice a la fecha mi intuición profesional es que, para mejores resultados en un proyecto de desarrollo, tengo la responsabilidad de seleccionar a los candidatos con un perfil científico básico: con un uso adecuado tanto de la razón como de la experiencia, y de una capacidad mínima para poner en tela de duda —para cuestionar— sus ideas previas sobre un asunto (y así dejar espacio para aprender algo nuevo).

¿Cómo ven? Todo esto está relacionado con un intento por tomar mayor conciencia sobre profesionalismo entre quienes practicamos el desarrollo de software como profesión.

Más al respecto en: (1) Why a Reflective Developer Program?, (2) El Programa para el Desarrollador Reflexivo - ¿de qué va?

Cualquier retroalimentación es bienvenida.