Imaginaos que un día os levantáis y decidís que queréis aprender a programar. Os puede parecer absurdo, pero ¿acaso no es absurdo que haya personas que fotografíen una tostada y la cuelgue en Instagram?
Lo primero es elegir un objetivo a largo plazo, una visión en la que nos imaginemos creando la reencarnación del PCFútbol, mi propia mascota virtual en el móvil o una web para colgar fotos de tostadas. Claro que a día de hoy no tenemos ni idea, pero esa visión será la que nos ayude a navegar entre las enormes cantidades de información, a superarnos y a elegir en cada momento las batallas adecuadas.
Tu visión personal será la que te ayude a aprender a programar.
Lo segundo es equiparse con todo lo necesario para programar. No queremos que por una mala planificación no podamos avanzar, y no sabemos qué otro día nos levantaremos con ganas. Para programar se necesitan 4 cosas:
Un ordenador adquirido en los últimos 10 años te vale. Y no tengas miedo, la programación no se va a cargar tu ordenador. Descargar películas y libros piratas sí.
La primera decisión de calado es elegir el lenguaje. Muchos habréis escuchado frases del tipo "Java es mejor que C++", "Javascript es el nuevo Java", "Lo mejor para empezar es Haskell" o "Yo programo en Excel". Paparruchas. Los que ya estén familiarizados con el mundo de la informática seguramente conozcan a E.W. Dijkstra [2], una de las voces más influyentes en la informática al que se le recuerda más por su chorrada de algoritmo [3] que por su apasionada obsesión por hacer programas que funcionen correctamente y su postura frente a la enseñanza de la programación. Detrás de los cientos de lenguajes de programación que existen, se encuentran no más de 5 paradigmas diferentes. Dijkstra defendía que el aprendizaje debía dirigirse hacia los paradigmas de programación en lugar de centrarse en los lenguajes. Cuando una persona aprende un segundo lenguaje, empieza ver las relaciones entre ambos y establece patrones comunes. Esos patrones son los que definen un paradigma. De esta manera, un programador que no aprende al menos dos lenguajes que siguen el mismo paradigma es un programador incompleto; y un programador que conoce un paradigma puede aprender un lenguaje en horas.
El objetivo debe ser aprender un paradigma de programación, no un lenguaje.
El primer objetivo en la formación de un programador debe ser el aprendizaje del paradigma de la programación estructurada. Aquí encajan lenguajes clásicos como C o Pascal. Sin embargo el paradigma predominante hoy en día es una evolución de la programación estructurada denominada programación orientada a objetos. Lenguajes como C++, Java, C#, Ruby o Scala siguen este paradigma. Como es deseable aprender varios lenguajes y la programación orientada a objetos introduce elementos innecesarios para las primeras etapas del aprendizaje, el lenguaje elegido será C.
El entorno de desarrollo es la aplicación (o conjunto de aplicaciones) que nos permitirá escribir código en un lenguaje y que de forma mágica consiga ejecutarlo. Será el encargado de hacer realidad nuestros sueños y de darnos a la vez muchos quebraderos de cabeza. Existen multitud de entornos de desarrollo y elegir el adecuado puede ser una tarea ardua. Yo os recomiendo que comencéis a utilizar Eclipse [1]. Escucharéis opiniones en contra y a favor. Mi consejo es que os evitéis debates espúreos y que lo descarguéis y lo instaléis. Es gratuito, está disponible en todos los sistemas operativos y soporta múltiples lenguajes. Así si un día cambiáis de ordenador o aprendéis un nuevo lenguaje, el trauma por cambiar de entorno será casi inexistente.
La definición de "buen libro" puede ser tan subjetiva como la de "mejor equipo de fútbol" o la de "mejor plato". Hay muchas posibles decisiones y cada persona recomendará uno distinto (algunos incluso a sabiendas de que es malo). Sólo hay una cosa peor que tomar una mala decisión y es no tomarla. Así que dejémonos de debates estériles y vayamos a hablar de EL LIBRO [4] de Herbert Schildt, para mi gusto el mejor escritor de libros didácticos de programación. Un libro con más ejemplos que texto no puede ser malo. Además obliga al lector a poner en práctica los conocimientos y a relacionarlos de forma constante, ofreciendo soluciones a todas las preguntas que plantea. Tiene libros de otros muchos lenguajes como C++, Java o C# que siguen la misma metodología y que son realmente buenos.
Este aspecto es más importante que cualquiera de los anteriores. Debes creerte capaz de hacer cosas y pensar en que algún día realizarás tu visión. Pronto aprenderás que los retos más difíciles pueden resolverse con facilidad y la mayor chorrada puede suponerte un enorme obstáculo. Pero al final todos los problemas se resuelven y la recompensa debe merecer la pena. Invierte tiempo en buscar tu motivación.
Muy fácil: equípate. Hazte con un ordenador, instala Eclipse CDT [1], localiza ese libro y dibuja tu visión. Pronto volveré con retos que espero que os motiven.
[1] Eclipse CDT.
[2] Puedes leer algo más sobre E.W. Dijkstra aquí.
[3] Si quieres saber qué es y para qué sirve el algoritmo de Dijsktra echa un vistazo aquí.
[4] Herbert Schildt. "C: Guía de autoenseñanza". Ed. McGraw-Hill 2001, ISBN 9788448132040. Lo podéis encontrar en la mayoría de bibliotecas universitarias.
Pablo Trinidad 6 septiembre, 2014
Posted In: Aprendiendo a programar, Tecnologería
Corrían los años 80 y los ordenadores personales comenzaron a hacerse un hueco en los hogares. Su aspecto y características eran de lo más dispares pero todos tenían un aspecto en común: nadie sabía qué hacer tras encenderlo la primera vez. Tan solo parpadeaba un pequeño cuadrado que parecía indicar que la máquina esperaba algo de ti. Así que tenías dos opciones: o leías un grueso manual o te conformabas con un pisapapeles muy caro. En aquella época todavía la lectura de manuales estaba bien vista, y las madres todavía eran capaces de manejar el video Beta o VHS con soltura.
Estos manuales eran monstruos de 500 páginas [1] que te entretenían durante más de 30 antes de poder tocar una sola tecla. Pero era entonces cuando se abría un mundo de comandos que hacían que poco a poco esa máquina inerte empezara a cobrar vida. Poco a poco aprendías a manejar procesadores de texto, dibujabas con el Dr. LOGO [2] y jugábamos a los primeros videojuegos. En mi caso, con un Amstrad CPC 6128 en mi poder y tras mucho sobar el manual acabé descubriendo un anexo titulado "Que usted lo disfrute" donde aparecían líneas de códigos indescifrables esperando a ser transcritos en el teclado con paciencia. En ese momento no sabías qué ibas a encontrar al final del camino, pero asumías el reto de explorar. El premio era doble: tenías un juego gratis (el gusto por lo gratis es intemporal) y descubrías que existía una forma de crear juegos y estaba a tu alcance. Mi padre, mi hermano y yo nos alternamos durante horas hasta que escribimos "RUN". Y de repente una pelota rebotaba por la pantala rompiendo cuadrados de colores. Y todos sentimos curiosidad por descubrir qué significaba aquel extraño lenguaje que nos daba el poder de controlar una máquina: el BASIC [3].
Algunos decidimos llevar esa curiosidad más allá, devorando los pocos libros y revistas que caían en nuestro poder para aprender a sacarle el máximo partido a la máquina para algún día poder controlarla. Así fue como muchos de una generación empezamos a crear nuestros primeros juegos (o un intento de ellos) y utilizábamos la programación como forma de expresar nuestra creatividad, tan válidas como el dibujo, la escritura, un regate de Mágico González o cualquier otro arte.
Y los profesores vieron que aquello era bueno. Los colegios que podían permitírselo (privados la mayoría) comenzaron a adquirir ordenadores personales y a impartir cursos en horario extraescolar y posteriormente como asignatura opcional en bachillerato. Ya existían por aquel entonces los primeros PCs con MS-DOS que seguía manteniendo la misma cara inerte de aquellos ya obsoletos ordenadores con su cursor parpadeante. No era extraño que en estos colegios pioneros se enseñara LOGO y BASIC. Su valor didáctico era indudable: resolver problemas haciendo uso de una herramienta con tantas posibilidades como una navaja suiza. Estos lenguajes tan básicos exigían al que los programaba pensar de una manera diferente, debiendo conocer qué era capaz de hacer la máquina y qué no. Te obligaba a estructurar la mente de una forma diferente, más creativa, más procedimentada. Y el premio final era suficiente como para que la motivación por resolver problemas no fuera un problema.
Tal fue el impacto de la programación en aquella generación que allá por el año 1997 se creó la I Olimpiada Informática Española [4], la edición española de su homólogo internacional que llevaba celebrándose desde 1989. El objetivo de esta olimpiada era fomentar la programación informática en los alumnos y profesores de institutos así como en las administraciones responsables de la educación [5]. En esta Olimpiada los alumnos debían resolver diversos problemas bien en lenguaje C, bien en Pascal. La mayoría de los institutos enseñaban BASIC con lo que aquellos alumnos que se manejaban con alguno de estos lenguajes era porque habían tomado un libro de la biblioteca municipal o que se había comprado un libro de programación en El Corte Inglés. A pesar de este requisito se consiguieron más de 400 participantes en toda España. Yo era uno de esos 400 y participé dos años seguidos, consiguiendo clasificarme para la fase final en Madrid a mi segundo intento. Aquella aventura no fue más allá de un 10º puesto en la final, pero todo aquello indudablemente marcó mi futuro y el de mucho de los allí presentes. La mayoría comenzamos los estudios de Ingeniería en Informática con la esperanza de seguir encontrando respuestas a nuestras inquietudes y convertir aquella afición en una profesión.
En los dos primeros años, cursas hasta 4 asignaturas de programación, salpicadas por otras 20 que en ese momento te parecen que no tienen nada que ver con la informática (a día de hoy 15 de esas 20 siguen en esa lista). Para mí fue sencillo: te enseñan lenguajes que ya conoces, aprendes algún algoritmo para resolver aquel problema que en su momento te llevó días y te das cuenta que los problemas que se planteaban en aquella Olimpiada eran tan difíciles o más que los que se plantean en la carrera. Para la mayoría de los compañeros el salto era brutal. Programar exige una forma de pensar diferente. No es sólo cuestión de aprender un lenguaje, que es pura sintáxis, sino que debes conocer sus implicaciones, cómo funciona una máquina, y debes comprender que tu forma de pensar y resolver problemas no es la forma en la que una máquina los resuelve. Debes desarrollar una habilidad para comunicarte con las máquinas en su lenguaje. Y ese lenguaje no es sólo C, Pascal o BASIC. Ese lenguaje requiere interpretar tu problema en base a problemas más pequeños, apoyarte en conocimientos matemáticos y comprender que un ordenador es la máquina más tonta del mundo que sólo es capaz de mover información de un lado para otro y hacer pequeñas operaciones aritméticas y lógicas. Y eso no se aprende viendo cómo un profesor habla, viendo cómo resuelve problemas en una pizarra o en su canal de Youtube. A hablar un idioma se aprende hablando, y a programar se aprende programando.
A día de hoy la mayoría de los alumnos que aprenden informática lo hacen sobre un papel. Y no sólo me refiero a la ingeniería informática sino también al resto de ingenierías que imparten programación. Para comprobar si un alumno sabe programar basta con vomitar líneas de código en varios folios y prueba superada (o no). ¿Acaso para demostrar que sabemos conducir nos basta con un examen teórico? ¿Acaso para aprender un idioma nos basta con demostrar que somos capaces de escribir? Y si encima esas pruebas utilizan la técnica de "rellena el hueco" para facilitar su corrección, el atentado contra el aprendizaje es aún mayor. Con este enfoque encontramos a multitud de alumnos que estudia con papeles y que va a tutorías a preguntar a un profesor si su programa funciona, teniendo el compilador al lado. Este tipo de enseñanza no persigue el desarrollo de mentes creativas, la resolución de problemas complejos, ni por supuesto se demuestra efectiva para discernir entre el alumno que es capaz y el que no. Con estas metodologías estamos creando dos universos en la programación: el que existe en el papel (que lo aguanta todo) y el que existe en el ordenador y sólo uno de ellos es real.
El número de alumnos no es excusa para justificar esta metodología. Las propias Olimpiadas y Google Code Jam [6] obtienen los resultados de forma inmediata con sistemas automáticos de puntuación; se organizan cursos masivos online con correcciones masivas. Con el papel lo único que logramos es que el alumno desconozca una parte importante de su práctica profesional, que adquiera un desdén por la programación y trasladamos el problema a años subsiguientes y por qué no, a las propias empresas que contratan a estos graduados. Es más, estoy convencido de que a día de hoy el 90% de los alumnos recién titulados en ingeniería de España son incapaces de resolver cualquier problema de una Olimpiada informática en un tiempo razonable.
Hoy retomo el blog con dos objetivos claros: Despertar el interés por la programacion y enseñar a pensar como un programador.
El año pasado no pude enviar a candidatos adecuados para 6 puestos de trabajo en diferentes empresas que buscaban a programadores excepcionales, con salarios muy por encima de mercado. Esto puede deberse a dos razones: mi incapacidad de encontrar talento existente en la Escuela y la incapacidad de la propia Escuela para crear talento. En cualesquiera de los dos casos, voy a intentar aportar mi granito de arena. Hoy retomo el blog con dos objetivos claros: Despertar el interés por la programacion y enseñar a pensar como un programador a quien se deje. Si no sabes programar, espero que te sirva para lanzarte a la piscina. Si te enseñaron mal, olvídate de todo. Si sabes programar algo, intentaré enseñarte amar la programación. Si ya sabes programar, colabora 😉
Para empezar a profundizar en estos objetivos en los próximos días publicaré distintos retos para cualquiera que se atreva a evaluar sus capacidades de programación, pensaré en voz alta y trataré de enseñar el apasionante mundo de la programación desde una perspectiva diferente. Espero conseguir "que usted lo disfrute".
PD: En algún momento organizaré alguna actividad presencial de la que informaré vía Twitter. Seguiremos informando.
[1] Si tuviste un manual AMSTRAD y eres un nostálgico échales un vistazo aquí.
[2] Aunque no lo creas LOGO sigue vivo. Échale un vistazo a su historia y evolución.
[3] Hay quien todavía usa BASIC en una de sus múltiples reencarnaciones.
[4] La Olimpiada Informática Española sigue existiendo a día de hoy
[5] Hoy mismo se anuncia que la comunidad de Madrid comenzará a impartir Programación este mismo curso en 15 institutos, ampliándolos a todos el curso 2015-16.
[6] Google Code Jam
Pablo Trinidad 4 septiembre, 2014
Posted In: Tecnologería
Si una empresa consultora especializada en servicios a la banca me invitara a dar una charla en sus instalaciones sobre algún tema del que supuestamente soy "experto", digamos en "procesos de negocio" por ejemplo, lo último que se me ocurriría es soltar en mitad de la charla una frase lapidaria del estilo "El problema es que vuestros jefes no tienen ni idea sobre el negocio". Nunca pondrías en evidencia a quien te ha abierto las puertas de su casa. Además has de saber que ese tipo de frases sólo se pueden soltar si eres consultor de negocio y los jefes te están pagando para decirles lo que todos saben pero nadie se atreve a decir.
Supongamos que la misma empresa consultora especializada en banca envía a su mejor hombre de negro por la Escuela Técnica Superior de Ingeniería Informática (en adelante ETSII) donde trabajas y se le ocurre soltar la siguiente frase:
"El problema es cómo enseñan Ingeniería del Software en la carrera"
Este mensaje promete ser la clave del éxito para conectar a ponente y audiencia, cuya predisposición hacia la crítica negativa del sistema educativo es bien conocida (yo mismo la tenía como alumno y la sigo teniendo parcialmente aun siendo profesor). Con ese mensaje los CVs van a llover y van a volver a captar los mejores perfiles de la ETSII para seguir presumiendo de ello ante sus clientes. Pero estamos en la era de la información y qué menos que esperar que en la ETSII, a alguien se le ocurra retwittear ese mensaje. Pero ¿a qué persona en su sano juicio se le ocurre ir a la casa que le abre las puertas para hacer gratis un proceso de selección y poner en entredicho la labor docente? Hay que ser cautos con la literalidad del mensaje escrito por terceras partes, pero si ese es el mensaje que llega a la audiencia el error es mayúsculo igualmente.
Casualidades de la vida que ese tweet llegue a leerlo uno de los profesores de ingeniería del software de la ETSII. Y más casualidad es que dicho profesor trabajara ya hace 10 años en la citada empresa y conozca algunos entresijos de la misma pudiendo dar fé de la completa ignorancia, al menos en aquellos tiempos, de todo lo relacionado con la tecnología, la gestión de proyectos y cualquier atisbo de principio básico de ingeniería del software. Todavía recuerdo cómo incorporaban a 2 técnicos nuevos la semana antes de una entrega; o cómo aumentaban el horario laboral en 2 horas diarias (sin pagarlas por supuesto) para no obtener mejora alguna en el rendimiento del equipo; o cómo realizar una planificación en Microsoft Project en la que todos los recursos estaban asignados al 400% con una semana laboral de 160 horas (una semana en general tiene 168 horas).
El día que me marché de la empresa, mis compañeros ingenieros gracias a los cuales pude subsistir el año y 1 día que estuve trabajando con esta empresa me regalaron el libro "El principio de Dilbert". Ese libro me ahorró el trabajo de escribir mis memorias. Ya con perspectiva puedo decir que no fue un año perdido en mi formación como profesional. Aprendí a moverme entre tiburones, a afilar los cuernos, a hacer valer el trabajo de ingeniería en contextos que son incapaces a priori de apreciarlo. Aprendí mucho sobre banca, sobre contabilidad y sobre todo aprendí lo que no quería hacer con mi vida.
Varios meses después y tras varios vaivenes profesionales acabé impartiendo clases en la ETSII. Gracias a esta ello muchos han sido los alumnos y amigos que me han pedido consejo sobre qué hacer con su vida profesional. Hasta hoy nunca había dicho explícitamente "no trabajes con esta empresa". A todos ellos siempre les he contado mi experiencia con hechos para que cada uno tomara sus propias conclusiones. Y tengo amigos que han dicho no a las consultoras y otros que sí, y de éstos algunos están contentos y otros me han dado la razón más tarde.
Actualmente son muchas las empresas start-up que están emergiendo a nivel nacional e internacional en el sector TIC. Ofrecen entornos dinámicos, retos apasionantes y sobre todo una sensibilidad y aprecio por el trabajo del ingeniero muy superior al resto de empresas de otros sectores. El mensaje de emprendimiento está calando y muchos se están atreviendo a crear productos nuevos gracias a las posibilidades de alcanzar el mercado con bajos costes gracias a las tiendas de aplicaciones. Con este escenario, ¿Cómo van las empresas consultoras a competir y a seguir captando talento? Mi historia tiene 10 años y es una de muchas, pero cuando este tipo de experiencias se repite hasta definir un tipo propio de empresa como son las "consultoras cárnicas" es normal que el tiempo ponga en su sitio a quien vende el don't-know-how por horas.
Espero que en estos 10 años los profesionales de esta empresa hayan aprendido tanto como para atreverse a venir a la ETSII a dar lecciones de ingeniería del software y a poner en entredicho la labor docente de un equipo de profesores que acumulamos en total varias décadas de trabajo para la empresa privada. Esto ocurrió hace ya un mes y lo dejé pasar hasta hoy, cuando me dice la simpática chica de recursos humanos de esta empresa que ha pasado por Imaginática que se marcha a casa con 8 CVs en su carpeta (a uno de ellos ya le he contado mi historia). Hace 12 años había que hacer cola en su stand. Y eso en tiempos de crisis da mucho que pensar. Tal vez los tiempos estén cambiando y estén recogiendo ahora lo sembrado en los últimos años. Tal vez sea que mucha gente me pregunta. Tal vez ya no les quede nadie a quien engañar. Tal vez la mina se está agotando. Y es que la política de recursos humanos es una inversión a largo plazo y tal vez ya sea tarde para cambiar.
Pablo Trinidad 3 mayo, 2013
Posted In: Desvaríos
Hoy toca a su fin la segunda edición de "21 días". El objetivo de esta iniciativa es concienciar del verdadero trabajo de un profesor universitario. Soy consciente de que no he publicado una avalancha de twits ni de entradas en el blog, pero ambas dos son actividades que consumen mucho tiempo, tiempo que en estos días por suerte o por desgracia no me ha sobrado. En concreto, en estas 3 semanas, con sus 6 días de fin de semana y 1 día festivo sólo he dejado de trabajar en dos ocasiones: domingo de Carnaval y hoy día de Andalucía. En estos 19 días de trabajo efectivo he realizado todas estas tareas:
Tenía pensado hacer otras muchas cosas, pero finalmente el concurso de ideas ha consumido mi tiempo y energías en los últimos días. En concreto quería haber enviado ya mi solicitud de acreditación a ANECA, haberle hecho más caso a mi doctorando y haber terminado la solicitud para crear un nuevo curso de experto. Así que todavía me quedan días y cosas por hacer como para que la lista anterior se quede corta en los próximos días.
Espero que después de esta "demostración" no sigáis pensando que los profesores universitarios impartimos 8 horas de clase semanales (en el peor de los casos) y nos vamos a casa. Por supuesto que haberlos haylos, y habrá que acabar con esas actitudes. Si alguna vez tenéis la oportunidad de entrar en nuestra Escuela un fin de semana, no es extraño ver a varios compañeros que están en sus despachos. Y los que trabajan desde casa, ya que con una conexión a Internet podemos realizar nuestro trabajo, excepto la docencia y algunas reuniones claro está, desde cualquier lugar del mundo. ¿Cuántos alumnos habrán recibido contestación a sus correos durante la madrigada? Así que cuando venga la próxima reforma de nuestro querido Ministro, por favor pensad en que las "soluciones generales" que intenten acabar con algunos problemas de la Universidad española, que no son pocos, también estarán acabando con profesionales que invierten su vida profesional y gran parte de la personal en sacar adelante la Educación y la Investigación españolas.
Y no me olvido que prometí acabar estos 21 días enseñando mi nómina. Pero es que nos van a bajar otro 5% adicional de todo el sueldo por cortesía y gracia de nuestra Junta de Andalucía. Saltándose esta vez la mesa sectorial y el convenio colectivo vigente del personal laboral en connivencia de los teatreros de UGT y CCOO Y como aquí la improvisación forma parte de la idiosincrasia de estos políticos mediocres que nos gobiernan, pues todavía no saben cómo instrumentalizarlo en la aplicación informática y aún no sé qué voy a cobrar este mes. Eso sí, se hará con carácter retroactivo en cómodos plazos. En cuanto sepa lo comunicaré a la mayor premura para que veáis el enorme pastizal que cobra un Ingeniero y Doctor en Andalucía.
Hoy toca descansar. Mañana seguiremos dando lo mejor de nosotros que es la única forma de que el futuro esté en nuestras manos y no en la de nuestros políticos.
Pablo Trinidad 28 febrero, 2013
Posted In: 21 Días, Reality Show
Una de las actividades más recurrentes del profesor de Universidad es la justificación de tu trabajo ante las distintas administraciones. Debes justificarte ante tu propia Universidad, ante tu comunidad autónoma, ante el Ministerio de turno y según el caso ante alguna Comisión europea. Y la forma más frecuente de justificación son los curriculum vitae (CV) en todas sus variedades. Pero en nuestro contexto, ese principio de "no más de 2 páginas" que es casi ley en la empresa privada no aplica en la mayoría de los casos. Aquí los CVs tienen varias decenas de páginas con méritos de todo tipo: publicaciones científicas, participación en proyectos de investigación y transferencia, docencia impartida, proyectos de innovación, cursos, formación, experiencia profesional previa,etc. Y en toda esta vorágine de información, no existe ni la libertad del investigador para elegir el mejor formato, ni un consenso en cuanto a qué formato debe utilizarse en la administración pública. Es por ello que cada administración utiliza un formato distinto según el objetivo:
Esta lista es incompleta, se me olvidan formatos con total seguridad así que la iré extendiendo a medida que me vayáis mandando vuestras contribuciones.
En los dos últimos meses he tenido que entregar un CVN para el doctorado, 8 CVs simplificados de mi tribunal de tesis, solicitar un sexenio, actualizar SICA2 y solicitar la acreditación como profesor contratado doctor para ANECA (en curso). Es muy importante que los indicios de calidad de tu trabajo estén convenientemente actualizados. Estos indicios varían según el mérito, como son los índices de impacto de revistas (el famoso índice JCR), las citas a nuestros trabajos (las fuentes más habituales son Google Scholar, Microsoft Academic Research, Scopus o Web of Science), ingresos económicos por proyectos o las entidades que explotan tu software o patentes. Estos indicios están "vivos" y en un mes pueden variar significativamente por lo que cada vez que debemos actualizar el CV el trabajo debe repetirse.
Con este modelo de constante justificación, se consumen un número importantísimo de horas en tareas improductivas. Ni estamos generando nuevo conocimiento, ni organizando nuestra docencia, ni transfiriendo los resultados a empresas. Estamos tirando el dinero del contribuyente a la basura. Además, la evaluación continua entierra ese principio básico de la investigación que dice que los beneficios de la I+D aparecen a los 5-10 años del comienzo de la actividad. Aquí se tiene en cuenta el éxito inmediato, siendo el éxito la publicación en revistas principalmente. Hay que publicar mucho en poco tiempo y la única forma de hacerlo es "lonchear" una buena idea y venderla por trozos en varios sitios. Además sólo se tiene en cuenta el éxito. Si en un año has tenido la mala suerte de ser rechazado por tres revistas, consta como si ese año no hubieras trabajado, con lo que se fomenta el no asumir riesgos.
En definitiva, si bien es importante ser consciente de tus avances y hacerlos explícitos a los demás agentes del sistema, la justificación constante ocupa un porcentaje altísimo de horas de trabajo anuales. No es algo eficiente y la miríada de formatos de CVs no ayuda a ello. Hay mucho margen de mejora, y si se quiere fomentar la calidad de la investigación española y atraer la inversión privada hacia las universidades, debemos ser eficientes en el uso de los cada día más escasos recursos de que disponemos.
Pablo Trinidad 9 febrero, 2013
Posted In: 21 Días, Reality Show