Me contaba un conocido los problemas que esta teniendo con una compañera a la que le cuesta 'aprender a programar'. Le decia que no es un problema de trabajo, sino de mentalidad. Simplemente no tiene esa capacidad de abstracción necesaria para codificar en un programa una forma de resolver problemas.
Eso hizo que derivara la conversación en los tipos de informatica. Una en la que se hace de todo (y se sabe de todo) y otra en la que simplemente nos limitamos a utilizar de la mejor manera posible unos programas prefabricados, sin poder tocar en ellos, ni modificarlos ni nada. Que permanecen como cajas negras. Esa informática es muy peligrosa, porque cuando se encuentra un problema que ese programa no puede resolver, nos quedamos desválidos, sin poder hacer nada para resolverlo (estamos atados al programa ese).
En la otra informatica, tienes unas herramientas, que por si mismas no hacen nada. Sirven de poco, pero que combinadas o modificadas (por uno mismo) para que se amplien, o con otras nuevas que tu te creas, das solución a todo lo que quieras. Para hacer eso tienes que tener conocimientos de todo. Tanto bajo nivel como alto nivel. No se trata de ser un experto en la API de la biblioteca XXX, sino de si esa biblioteca no te sirve, poderte hacer otra biblioteca con otra API y combinarla (o sustituirla) con la otra llegado el caso.
Eso define al informatico de vocación y al informatico de obligación (o de papeles). Al primero le fascina su trabajo. El segundo es un simple operario, que hace las tareas de forma mecánica y cuando algo no funciona en su cadena de montaje, se queda parado esperando a que mágicamente se ponga en marcha. No es consciente de que existe un informático de vocacion debajo de la cadena de montaje intentando buscar, encontrar, soluciónar el problema.
Recuerdo una entrevista de trabajo que hicieron en una empresa en la que estuve trabajando. Alli se presento un candidato con currículum impresionante. Experiencia laboral, con la carrera y permio proyecto de fin de carrera (realizado en VB) entre otras cosas, ademas de experto en VB. Le hicimos una prueba, que consitia en hacer un programa en VB para que pidiera login y pass a un usuario, hiciera una conexion con una bd y contrastara los datos antes de seguir para adelante. Durante la prueba se permitia el uso de documentación, la que considerara oportuna. El objetivo de la prueba no queria ver lo rápido que lo hacia ni nada, sólo la soltura del candidato creando un proyecto con VB, organización de ficheros y claridad del código.
El candidato nos dijo que eso no podia ni sabía hacerlo, que él lo programaba pero que siempre le habian dado los proyectos de VB hechos y abiertos, y se limitaba a crear módulos dentro de un proyecto. O sea, que no era capaz de crear un proyecto desde cero. Sólo sabía añadir módulos y formularios en proyectos de VB.
Por curiosidad, contrastamos si nos habia mentido cuando nos envió el currículum. No nos mintió en su experiencia, ni titulación ni en el premio del proyecto. Solo que no era un 'experto' en VB. Un experto tiene otra actitud.
Eso hizo que derivara la conversación en los tipos de informatica. Una en la que se hace de todo (y se sabe de todo) y otra en la que simplemente nos limitamos a utilizar de la mejor manera posible unos programas prefabricados, sin poder tocar en ellos, ni modificarlos ni nada. Que permanecen como cajas negras. Esa informática es muy peligrosa, porque cuando se encuentra un problema que ese programa no puede resolver, nos quedamos desválidos, sin poder hacer nada para resolverlo (estamos atados al programa ese).
En la otra informatica, tienes unas herramientas, que por si mismas no hacen nada. Sirven de poco, pero que combinadas o modificadas (por uno mismo) para que se amplien, o con otras nuevas que tu te creas, das solución a todo lo que quieras. Para hacer eso tienes que tener conocimientos de todo. Tanto bajo nivel como alto nivel. No se trata de ser un experto en la API de la biblioteca XXX, sino de si esa biblioteca no te sirve, poderte hacer otra biblioteca con otra API y combinarla (o sustituirla) con la otra llegado el caso.
Eso define al informatico de vocación y al informatico de obligación (o de papeles). Al primero le fascina su trabajo. El segundo es un simple operario, que hace las tareas de forma mecánica y cuando algo no funciona en su cadena de montaje, se queda parado esperando a que mágicamente se ponga en marcha. No es consciente de que existe un informático de vocacion debajo de la cadena de montaje intentando buscar, encontrar, soluciónar el problema.
Recuerdo una entrevista de trabajo que hicieron en una empresa en la que estuve trabajando. Alli se presento un candidato con currículum impresionante. Experiencia laboral, con la carrera y permio proyecto de fin de carrera (realizado en VB) entre otras cosas, ademas de experto en VB. Le hicimos una prueba, que consitia en hacer un programa en VB para que pidiera login y pass a un usuario, hiciera una conexion con una bd y contrastara los datos antes de seguir para adelante. Durante la prueba se permitia el uso de documentación, la que considerara oportuna. El objetivo de la prueba no queria ver lo rápido que lo hacia ni nada, sólo la soltura del candidato creando un proyecto con VB, organización de ficheros y claridad del código.
El candidato nos dijo que eso no podia ni sabía hacerlo, que él lo programaba pero que siempre le habian dado los proyectos de VB hechos y abiertos, y se limitaba a crear módulos dentro de un proyecto. O sea, que no era capaz de crear un proyecto desde cero. Sólo sabía añadir módulos y formularios en proyectos de VB.
Por curiosidad, contrastamos si nos habia mentido cuando nos envió el currículum. No nos mintió en su experiencia, ni titulación ni en el premio del proyecto. Solo que no era un 'experto' en VB. Un experto tiene otra actitud.
No hay comentarios:
Publicar un comentario