Monday, April 18, 2005

Ingeniero?


Alguna vez estuve en una conferencia con el gerente de recursos humanos de la Fundación Corona. Una de las muchas cosas que decía el tipo era que las Universidades eran unas asesinas de la diversidad. Cuando uno entra es simplemente una persona, cuando sale ya lleva un rótulo, por lo que la profesión lo limita a uno. Como uno ya es ingeniero, pues eso conlleva toda una serie de mapas mentales ya definidos y una serie de formas de pensar.


Yo creo que yo ya era ingeniero desde mucho tiempo antes de realmente serlo, y ahora que ya realmente lo soy me esta tocando dejar de serlo. Como lo dice Joel Spolsky en su tradicional curubito de porrista de la pequeña empresa de software, y como ya había sido dicho mas de un millón de veces. Hacer software es acerca de mucho mas que hacer software. De hecho, ni siquiera el 50% de lo que implica ganarse la vida haciendo software es hacer software. Es cierto que hay millones de programadores que se ganan la vida solo disparando código, pero realmente, un puesto de esos no es realmente divertido, porqué con la división actual de labores uno termina trabajando en una parte diminuta del código de presentación de un módulo diminuto de la aplicación de varios miles de millones. No lo he hecho, pero supongo que los trabajos divertidos, o estimulantes en esa área no son los de programador raso.
Dicho esto, entonces, ser ingeniero es muy bueno para formar el core técnico de una compañía se software, pero de pronto no lo es tanto para dirigirla.


La razón, desde mi punto de vista, es una muy sencilla: Imparcialidad. Los ingenieros tendemos a ver el software como mas que un programa que facilita la vida, o simplemente un producto que se vende. Para nosotros el software tiene muchas más implicaciones, muchas mas facetas.


Antes pensaba que la Administración de Empresas era una carrera a la que se dedicaban quienes simplemente deseaban ser jefes, sin importar de qué. Ese hecho les da la capacidad de mirar las cosas de una manera mas práctica, como entradas y salidas. Se necesitan unos recursos A, se obtienen unos recursos B. B>A entonces todo esta bien. No importa si el código que esta debajo es horrible, o si usa doscientos mil APIs propietarios, y es tecnología enteramente cerrada.

No comments: