Piola vago

En nuestras frecuentes charlas de facultad surge el debate permanente acerca del nivel de preparación que se exige a un alumno para aprobar tal o cual materia, de los contenidos que tiene o debería tener esa materia, de la manera de articular las materias dentro de la carrera, etc.etc.etc. En algún momento el tamiz parece llevarnos a diferenciar dos grandes corrientes:

• los técnicos
• los no-técnicos, aquellos que se jactan de no saber programar, o lo dicen poniendo la misma cara de no tener encendedor porque "no fumo, ¿viste?". 

Los de la primera oleada son acusados de nerds, de no poder trabajar con "herramientas más abstractas", de ser poco amables (en mi laburo se solía decir "es áspero porque es muy técnico"), y por ende se busca que los usuarios no hablen con ellos. El ghetto se completa porque los técnicos se ríen de los no-técnicos, saben que el resto del mundo no los entiende y las veces que alguien intenta cambiar esta situación alguien sale herido.

Ya tempranamente podemos ver esos aparentes perfiles en los alumnos:

• tipos que disfrutan del código: se les ve en las caras, les brillan los ojos cuando conocen el orden superior, quieren saber de qué está hecha la ALU, o bien adoran implementar un ORM porque pueden conocer así ambas formas de modelar la información
• los otros se escudan en que "no me gusta mucho programar", "me cuesta", "no debería programar en la materia XXXX", "me parece mal que se enseñe codificación porque acá se deberían ver herramientas de más alto nivel".

Ahora bien, el desarrollo de software necesita sí o sí la pata técnica: para armar la arquitectura requerís conocimientos técnicos, para diseñar los componentes necesitás saber tecnológicamente qué restricciones aplican (en cuanto al paradigma y a la arquitectura), y para liderar un proyecto necesitás conocer la naturaleza que tienen los productos de software. 

Entonces decir "no me gusta lo técnico" te deja afuera de un montón de lugares que podés ocupar en un proyecto de software. ¿Dónde encajás?

1. Siendo project leader (creyendo que podés coordinar la construcción de un puente, llevar adelante un proyecto de Smart TV o bien dirigir a los científicos que encuentren la vacuna contra el SIDA)
2. Siendo usuario (haciendo que los demás te construyan sistemas)
3. Siendo gerente
4. Siendo más que gerente (CEO, director)
5. Siendo un vendedor "técnico" pero que no le gusta lo técnico
6. Siendo un "consultor" inespecífico
7. Tener una consultora (ver punto 4)
8. O siendo un funcional que no puede diseñar, o "no le gusta diseñar".

Pero ¿cómo anda esta gente en lo gestional? 

Por supuesto, algunos bien y muchos mal. 

En el primer caso los he visto y muchos fueron compañeros de trabajo: tipos que dijeron no me caso con la tecnología pero fueron buenos funcionales, armaron buenos modelos, rebatieron mis ideas con fundamento y me ayudaron a mejorar, o fueron respetuosos PM/PL (project leaders), confiaron en mí que fui su pata técnica, donde confiar es verdaderamente confiar cuando uno dice "está todo bien" o "está todo mal", cuando uno dice "son 8 horas y no 4", cuando frenan la ansiedad del usuario o me dejan a mí para que lo convenza de algo.

A los que entran en la segunda camada la cosa está difícil para defenderlos: ok, no les gusta lo técnico pero en lo otro también hacen agua. ¿Qué les pasa? ¿Qué objetivos persiguen?

Mi conclusión al día de hoy es que se trata de gente que está flotando: buscan hacer la plancha (no se gana tan mal en sistemas), sólo contestan mails para cubrirse, delegan todo el trabajo y la presión a los que pueden responder. Son mediocres. No transmiten pasión porque no la tienen, no hay fuego en su interior. No son sommelliers de productos de software: ni siquiera pueden distinguir una obra de arte de un pedazo de excremento. También los he visto: alumnos y compañeros de trabajo (funcionales, PM, gerentes e incluso técnicos). Por eso pido perdón a la generalización de "funcional = no tenés huevos" que se extiende en nuestra comunidad nerd. No es justa la simplificación. 

Sí sabemos que es más fácil "robar" y transigir en zonas grises como funcional que como técnico, porque en definitiva lo que no se analiza, lo que no se diseña, los casos de prueba omitidos se cubren con desarrollo o con bug-fixing. Lo mismo da en la facultad como en lo comercial: 

• si en la clase de Decorator hago un diagrama de clases que esté mal, apuesto a que sólo un 20% lo puede detectar, 
• pero si además del diagrama lo implemento y corro un test unitario y no funciona, se ve. Sale un rojo, eh. 

Y les dejo para el final apuntes de dos compañeros de ruta:

Miguel Carboni: "Hay una moda de disimular la falta de solvencia técnica alegando

cierto destino manifiesto de gestor (bastante improbable por cierto).
Es como una escuela de medicina donde nadie aprende anatomía confiando
en que al recibirse va trabajar dirigiendo un servicio o un hospital."


y Nico Passerini: "No hay una discusión técnico vs. no-técnico, solamente hay gente que no tiene ganas de aprender... y cree que siendo no-técnico se va a notar menos.

Pero también están todas las cuestiones humanas y de la visión que ellos tienen de cómo se organiza una empresa, la visión de la jerarquía, de la autoridad, del mando. Por eso, en esa visión para ser jefe no se necesita saber nada más que manejar bien el látigo."

Que la pasen lindo.