Antes, los oficios eran más o menos hereditarios o para toda la vida. El hijo del herrero, del zapatero, del curtidor aprendían el oficio de su padre o maestro. Cuando llevaban muchos años de aprendices, heredaban el negocio y se convertían en maestros de nuevos aprendices.
Actualmente, todos preferimos a un zapatero que sea un señor mayor, que lleva toda su vida en una zapatería cutre, que a una de esas tiendas de arreglo de zapatos modernas, en las que hay un chico joven en una tienda muy de moda en un centro comercial.
La situación actual con la programación no es muy distinta, ya que se contrata para programar a un recién salido -da igual la titulación, FP, media o superior- Cuando empieza a adquirir algo de experiencia -uno o dos años-, es cuando se empieza a considerar que es un fracasado si sigue programando. Hay que ascenderle y darle responsabilidad de alguna manera. El mismo programador pide dicho "ascenso" o se va a otra empresa a buscarlo. Cuando empieza a adquirir experiencia, lo ponen a diseñar, a llevar un proyecto, de jefe o lo que sea.
Yo llevo años programando -ni me gusta ser jefe ni quiero serlo- y sin necesidad de cambiar de tecnología ni de lenguaje, aprendo cada día nuevas formas de hacer las cosas, descubro nuevos "trucos" del lenguaje de programación que uso. Y lo que es peor, descubro cosas que llevo años haciendo mal y deberían hacerse de otra manera.
Aunque mi conocimiento de lenguajes es limitado -java y C++ para unix-, y aunque mi cabeza quizás no me da para resolver rápidamente un algoritmo complejo, todos estos años programando me han hecho aprender muchos trucos del lenguaje, creo comprenderlos bien y me siento cómodo con ellos. Mi experiencia con la gente nueva, incluso aunque sepan java o C++, es que hay que enseñarles. Los hay más o menos espabilados, pero es raro que vengan con los conceptos claros, con conocimientos profundos del lenguaje, con sus trucos aprendidos. Simplemente, les falta experiencia en la programación con ese lenguaje.
Según lo veo yo, debería haber gente que les guste y se queden muchos años programando, que no consideren que programar muchos años es un fracaso -la mayoría lo piensan-. Estos deberían empezar como aprendices de alguien con varios años de experiencia, como los antiguos aprendices y deberían empezar a hacer código casi casi guiados de la mano. Prácticamente se les debería dar la clase o la función preparada simplemente para rellenar el código interno y deberían ser supervisados por el "maestro" con varios años de experiencia.
De esta forma, poco a poco y sin causar grandes desastres en los proyectos, irían aprendiendo los intríngulis del lenguaje, adquiriendo experiencia e independencia, la forma correcta de hacer las cosas, hasta ser capaces de tirar por sí solos y empezar a "enseñar" a otros nuevos aprendices.
Desgraciadamente, no es así. En los sucesivos proyectos de mi empresa, a lo largo de los años, se mete la pata en lo mismo una y otra vez, porque los que codifican siempre son los nuevos. Los expertos ahora son jefes y no tienen tiempo de meterse con el código. Y los nuevos que codifican lo hacen casi sin ningún tipo de guía y meten la pata en las cosas normales que puede meter la pata uno nuevo una y otra vez, y otra vez y otra vez más: Conexiones a base de datos que se quedan abiertas, hilos que se bloquean, ventanas que se van detrás, interfaces de usuario prácticamente iguales que se comportan distinto, tareas simples que se hacen muy lentas por usar algoritmos ineficientes, código excesivo que se hace con muy buena intención, pero en la práctica no sirve, etc, etc, etc.
August 7th, 2007 at 6:48 pm
Mi experiencia a nivel profesional es prácticamente nula, eso de primeras. Pero no llego a entender por qué se tiende a poner jerarquías tan fuertes en grupos de desarrollo. Para mi un analista que no programa no es un buen analista, un director de proyectos que no sea analista y programador, no es un buen director. Personalmente diría que en un proyecto, todos tienen que programar, un subgrupo debería de realizar el análisis (y nadie dice que ese subgrupo no sea igual al grupo total), y uno debería de organizar (y tampoco digo que sea un rol fijo, aunque por organización debería, algo tipo scrummaster). Quizá puede que suene utópico, pero no debería.
August 8th, 2007 at 9:13 am
Según lo veo yo, todo es cuestión de dinero. Sale mucho más caro formar a los nuevos “fichajes” utilizando personal interno que el que se formen ellos mismos mediante la prueba y el error. Supongo que por eso tienen éxito las empresas de servicios que venden la moto prometiendo programadores bien formados cuando en realidad acaban de salir de la facultad…
En fin, sólo es mi punto de vista.
Por cierto, enhorabuena por tu blog.
August 8th, 2007 at 9:48 pm
A riesgo de que este comentario parezca burda publicidad igual puede que consideres interesante esta entrada que escribí hace unos días sobre las categorías laborales en Irlanda (http://brigomp.blogspot.com/2007/08/categoras-en-it-dentro-de-irlanda.html).
Yo estoy trabajando aquí, y como comento en el post (y es lo que me lleva a enlazarlo aquí) en este país no es una verguenza estar programando, aunque tengas veintimuchos, treinta, cuarenta, o lo que sea.
Saludos,
Martín
July 2nd, 2009 at 11:41 pm
El problema es que al 90 % de los que salen de las facultades de sistemas, oh sorpresa !, no les gusta programar !
Entonces por que estudiaron esa carrera?
Pues por que es glamorosa, esta de moda, es el futuro o cosas asi.
En cuanto llegan a una empresa buscan otro puesto, y generalmente lo obtienen en donde hacen menos danio, si recordamos el principio de Dilbert, la gente incompetente debe ser puesta en lugares donde no cause danio, generalmente en los mandos, de esa manera no afecta los proyectos, y los que de verdad saben los sacan adelante.
Pero claro no es una regla inflexible, solo un principio general de la naturaleza. Por eso, si quieres conocer a alguien que de verdad sepa, busca un programador, quien en las empresas de sistemas es quien realmente sostiene la empresa.