Cuando empezamos a trabajar en una empresa, lo normal es que empecemos como programadores (cobrando poco). Símplemente alguien nos dice qué código tenemos que hacer, mejor o peor especificado, lo hacemos y hemos cumplido.
Con el tiempo, si somos buenos programadores, hacemos nuestras tareas rápido, nuestros programas son vistosos y no dan problemas, posiblemente nos "asciendan". Esto significa que seguiremos cobrando lo mismo, pero que pondrán a nuestro cargo a un grupo reducido de programadores más novatos que nosotros, recién llegados.
Nos darán a nosotros el trabajo de tres o cuatro personas, nosotros lo organizaremos con los tres o cuatro que tenemos a nuestro cargo y haremos el código. Ahí es cuando se nos plantea más claramente, si somos programadores astutos, una nueva necesidad. Dos de nuestros muchahos tendrán que hacer cosas distintas, pero una parte será muy parecida del uno al otro, no igual, pero sí con cierta semejanza.
Si somos espabilados buscaremos la forma eficiente de hacer ese algo parecido, es decir, que uno de ellos lo haga de forma que sirva para los dos. Esta necesidad hará, si no lo hemos hecho todavía, que empecemos a descubrir la verdadera potencia de la orientación a objetos (que va más allá de heredar, sobrecargar algún método e implementar alguna interfaz). Descubriremos cómo dos códigos distintos, pero con una leve semejanza, pueden hacerse con una gran parte de código común. Descubriendo la potencia de la orientación a objetos, veremos cada vez más códigos menos semejantes que pueden hacerse en común y descubriremos nuevamente más potencia en la orientación a objetos.
Ahí llegamos a un bucle sin fin. Siempre vemos formas mejores de hacer las cosas, de aprovechar y generar más código común, de usar de una nueva forma el polimorfismo, y podemos pasarnos años haciendo una y otra vez lo mismo, pero cada vez de forma más eficiente y aprendiendo más. Por lo que yo se por experiencia y por lo que he leido, siempre se está aprendiendo … pero vas olvidando el código puro, ya que cada vez codificas menos y piensas más en lo que tienen que codificar los demás.
Sin embargo, este bucle sin fin tiene un fin. Un nuevo ascenso. Como tu grupo, según tus jefes gracias a tí, es un grupo eficiente que cada vez hace mejor las cosas, te vuelven a ascender. Esta vez eres jefe (cobrando lo mismo), de varios grupos como anteriormente era el tuyo. Ya es demasiada gente, ya no te puedes meter en el código en absoluto y casi vas perdiendo de vista las clases UML. Ya tienes que empezar a pensar en paquetes, ejecutables, librerías y dejar que tus sub-jefes (que siguen cobrando lo mismo que cuando eran programadores), piensen el diseño detallado.
Este es el principio del fin de quedarse obsoleto. Pierdes totalmente el contacto con el código. Apenas ves diseño detallado y sólo piensas en alto nivel, en abstracciones. En cuanto lleves unos años en ese puesto, cambiarán el lenguaje de programación, saldrán nuevas tecnologías y ni siquiera servirás para hacer un diseño de alto nivel de esas cosas. Si sabías un montón sobre aplicaciones de escritorio, no puedes hacer un diseño en EJBs, sobre todo porque ni siquiera sabes qué demonios es un EJB. Al final acabas de ser totalmente inútil y es el momento en que te ascienden a jefe de verdad (y es el momento en que te suben el sueldo).
