Etiquetas
En mi apunte anterior «Lo que demanda el mercado…» critiqué la obstinación de algunas autoridades universitarias, especialmente las de la mía, en su posicionamiento extremamente conservadora contra el GNU/Linux… y cómo el tiempo les ha quitado la razón (yo diría que debería haberles avergonzado). A pesar de los dos enlaces que puse en la posdata, muchos interpretaron que pensaba que la universidad debe enseñar GNU/Linux porque tiene más salida laboral. Otros opinaron (sobre todo en Twitter) sobre lo poco que se aprende en la universidad de las últimas tecnologías [de moda].
Hace cinco años escribí un apunte muy largo sobre este tema: Sintonizar universidades y empresas, pero ¿qué debe saber un ingeniero? (y hay más, de gente más importante y valiosa que yo, como ¿Qué deberíamos enseñar a los nuevos desarrolladores? de Bjarne Stroustrup), ahora intentaré ser muy breve para contestar a esos dos temas.
No creo en ello, ni afirmé, que se deba enseñar GNU/Linux porque es lo que demanda el mercado, sólo demostré la falacia de justificar su casi prohibición en la universidad basada en el argumento que no es lo que el «mercado quiere», o que es «poco profesional» (prometo que me cansé de oír esas frases repetida por los burócratas de las TI de mi universidad).
No sé qué tecnologías se usarán dentro de diez años, pero vista la evolución actual (Linux hasta en los bolsillos…), apostaría a que es más probable que siga habiendo un uso importante de Linux y sistemas derivados. Con lo que eso provoca social, económica, y empresarialmente.
Aún así, no me cerraría en ello, si viese que surgen alternativas diferentes, tecnológicamente seductoras, prometedoras, y con una comunidad de frikis early adopters entusiasmados, las analizaría con mucha curiosidad y dejaría que esa comunidad crezca y ponga sus herramientas al límite. Si fuese una autoridad académica, haría lo posible para favorecer esas iniciativas, porque no podemos estar seguro de si será nuestro entorno profesional del futuro.
Lo que nunca haría es basar decisiones universitaria-académicas únicamente a lo que el «mercado demanda», y mucho menos intentaría perjudicar a iniciativas alternativas al status quo. Sólo de una cosa estoy seguro: el status quo tiene caducidad, aunque no sepamos la fecha.
Por otro lado, son típicas las quejas del tipo (ejemplo real, de Twitter)
Salí de la universidad sin saber qué era un servidor de aplicaciones. ¡Qué atrasados!
En este caso en particular, no veo el problema. Un servidor de aplicaciones es sólo un servidor que implementa paso de mensajes distribuidos con mecanismo de rendevouz cliente-servidor (i.e. el servidor espera por conexiones que inician los clientes), y sincronización general de llamada a procedimientos remoto (i.e. bloqueo del emisor hasta recibir respuesta del receptor, en este caso el servidor), con técnicas para minimizar los tiempos de esperas, como mantener un pool de hilos en marcha (i.e. temas simples de gestión de procesos).
Conociendo esos temas fundamentales -los estudiaron en redes y algoritmos concurrentes y distribuidos- no hace falta conocer al detalle la tecnología de un fabricante o plataforma en particular (en este caso seguramente se refería a la plataforma Java 2 Enterprise Edition) para poder coger el manual y empezar a producir en pocas horas.
Otro tipo de queja habitual es (elijo este ejemplo porque además incluye el hype de moda, NoSQL):
Tuve dos asignaturas de bases de datos relacionales, y cuando voy a una empresa usan NoSQL, que nunca vimos en la universidad ¡Qué atrasados!
Parece creer que las base de datos relacionales tuviesen los días contados, y no involucrase conceptos importantes como álgebra, almacenamiento, atomicidad, concurrencia, serialización de operaciones, etc. Pero lo más importante, el NoSQL es sólo volver a usar los viejos sistemas de bases de datos simples con hashes o B-Trees pero con esteroides: replicación, distribución, índices multi columnas. Con saber los conceptos básicos de ficheros, estructuras de árboles de búsquedas, consultas algebraicas (estudiadas en base de datos) y algoritmos distribuidos ya se tienen las nociones importantes para saber cómo funcionan e implementan esos sistemas. No tiene sentido que se pierda tiempo aprendiendo los detalles de Redis, Memcached, Cassandra, MongoDB, etc. durante la carrera. El tiempo es limitado, y quizás cuando acaben la carrera en un par de años, esas herramientas hayan cambiado mucho.
Un problema es no saber distinguir los conceptos fundamentales de las implementaciones tecnológicas particulares (y el hype de los vendedores de la plataforma). El otro problema es no saber que, aunque se quejan del tiempo que pasan en clases, el tiempo es finito y es imposible enseñar y entrenar en cada una de las tecnologías y productos que se usan en el mercado. Menos aún si queremos formar a los alumnos para que sean profesionales en cualquier «mercado», no sólo en el que rodea a cada universidad.
Estos temas más locales, o de formación más profesional -es decir, con entrenamiento que demanda el mercado- deberían dejarse en todo caso para los master profesionales.
Pequeño bonus
Muchos se preguntarán qué conceptos fundamentales deberían conocerse en la carrera, no puedo hacer una lista exhaustiva, pero aquí van unos pocos ejemplos.
Programación en C. Es un lenguaje muy sencillo, pero que obliga a pensar y programar a un nivel muy próximo a la arquitectura de ordenadores. Por ejemplo, saber cómo se almacenan los datos en memoria, y la necesidad de manipular punteros. Esto de una idea del trabajo de los compiladores e intérpretes de otros lenguajes a la hora de convertir gestión de estructuras sofisticadas al nivel de ejecución.
Estructuras de datos. Arrays, listas, colas, pilas, colas con prioridad, heaps, hashes, árboles balanceados, árboles balanceados de búsqueda, árboles radix, representaciones de grafos, B-Trees.
Algoritmos fundamentales. Se debería conocer los algoritmos de ordenamientos y sus análisis de complejidad, diferencias entre P, NP y NP completo, implementar de memoria al menos el quicksort y mergesort. Recursividad, algoritmos de grafos, se debería saber implementar de memoria un depth-first-search, breadth-first search (y su «primo», el algoritmo del camino más corto de Dijkstra), backtracking, manipulación y operaciones de datos binarios, programación dinámica, algoritmos distribuidos, operaciones matriciales, patrones de strings, expresiones regulares, geometría computacional, etc.
Programación orientada a objetos. Dominar al menos un lenguaje orientado a objetos, como C++, Java, C# o incluso Python (con objetos).
Conceptos básicos de sistemas operativos. Gestión de memoria, de procesos, sistemas de ficheros (se debería ser capaz de implementar un sistema de ficheros completo, uno basado en i-nodos no toma más de 2000 líneas en C, un FAT es aún más sencillo).
Gestión de procesos y concurrencia. Los procesos son la unidad de ejecución fundamental, hay que conocer cómo están estructurados y gestionados por el sistema operativo, y los problemas de acceso concurrente a recursos compartidos (secciones críticas, exclusión mutua, interbloqueo, esperas infinitas, spinlocks, instrucciones de hardware, mutexes, semáforos, monitores, lectores escritores, mensajes, sincronización, etc.)
Administración de Sistemas. Linea de comandos en Unix, programación en shell y en al menos otro lenguaje de scripting como Python, Perl o Ruby. Gestión de procesos, usuarios, grupos y permisos. Comandos más utiles y usados, grep, find, awk, sort, netcat, tcpdump… Sistema de arranque. Configuración de correo, servidores web, interfaces de red, ssh (y derivados), gestión de claves y certificados, manipulación y recuperación de sistemas de ficheros, sistemas de ficheros remotos (NFS, SMB…).
Esta es una lista pequeña e incompleta, pero creo que forman parte del «núcleo», de lo que considero debe dominar un ingeniero informático cuando acaba su carrera, en cualquier de las ramas. La mayoría de ellos se estudian en clases (o deberían), pero hay otros que son de «cultura general», o que deberían aprender los alumnos por sí mismos. Por ejemplo, no tiene sentido que se dediquen horas de clases a enseñar programación en shell o ssh, sino que cada uno debe estar motivado para aprenderlo durante su carrera, o el profesor incentivar a que lo hagan, porque también facilitan el trabajo a los alumnos.
Si eres ingeniero informático y hay algunos de esos temas que no sabes, todavía tienes tiempo de aprender. Muchos de los temas que menciono los aprendí después de acabar la carrera -imagina el nivel, además la hice cuando no había libros de textos de algunos de los temas más novedosos-, a otros los aprendí de verdad cuando tuve que enseñarlos. Es en ese momento cuando te das cuenta de los agujeros del conocimiento que tienes (es la mayor ventaja de dar clases).
En el caso de la universidad, los he aprendido luego de la universidad y en mi tiempo libre (aún cuando estudiaba) otros si eran temas de la universidad.
Coincido contigo en casi todo, pero no veo conocimientos en cálculo computacional, métodos numéricos, Fundamentos Físicos, Dispositivos electrónicos entre otras…No sé como estarán los Graduados ahora mismo, pero yo hice todas esas asignaturas y prácticamente no recuerdo casi nada de ellas. Tal vez porque no las he vuelto a utilizar desde que las aprobé. En su momento estoy seguro de que aumentaron mi capacidad de concentración, mi tenacidad, mi cultura general o algo que no podría medir ahora mismo, pero a día de hoy dedicándome al desarrollo de software, echo en falta más tiempo en cosas que marcas como importantes (Conceptos básicos de sistemas operativos y Gestión de procesos y concurrencia) preferiría que se hubieran dado de forma mas pausada y con mas «mimo».
Tampoco se ofertaban asignaturas de libre configuración u optativas para fortalecer estos conceptos con los lenguajes de script que sugieres. Las alternativas ofertadas en mi caso eran ampliación de Física, Matemáticas o Cálculo o relacionadas con la electrónica.
El punto de vista del estudiante cuando está estudiando es bastante parecido al de un naufrago que acaba de llegar a una isla, realmente no tienes ni idea de lo que vas a utilizar y lo que no. Tal vez situaciones prácticas reales como el servidor de aplicaciones sirvan para motivarte y el tiempo para montarlo con las tecnologías actuales dudo que supere un par de clases.
En mi opinión creo que en la universidad falta motivación para el alumnado, que a todas esas cosas que indicas se les vea utilidad y no algo que superar para aprobar la asignatura.
Enhorabuena por el blog, se aprende bastante con las cosas técnicas y en otras aunque no opine igual, ayuda a reflexionar.
Un saludo,
@Jose Alberto
> Coincido contigo en casi todo, pero no veo conocimientos en cálculo computacional, métodos numéricos
Lo dije explícitamente:
pero aquí van unos pocos ejemplos
Esta es una lista pequeña,
Voy a agregar «incompleta» a la segunda frase, porque se ve que no queda claro que no pretendía escribir la currícula completa de una carrera de informática 😦
Ya sé que la lista no es exhaustiva O:) pero yo añadiría conceptos básicos de redes, y programación funcional. Redes porque casi todo lo que se hace actualmente es en red y estoy harto de que la mayoría (ingenieros, de la UIB, trabajando ya) se hagan la pirula un lio con chorradas básicas de TCP/IP o piensen que el DNS se basa en una combinación de la Fuerza (de Star Wars) y el bosón de Higgs. Y lo de la programación funcional, porque al menos da una visión de que hay más maneras de pensar, resolver problemas y programar… y creo que es una herramienta más útil, cuanta más concurrencia tienes. Puedo equivocarme, pero yo ahora mismo creo que cada vez se hará más programación funcional, al menos mientras los fabricantes de CPUs escalen añadiendo cores porque es más fácil que hacer cores individuales más rápidos.
@Guillem
De tercero de la UIB soy, y estamos ahora con LISP y a muchos nos está molando bastante.
Lo de redes si se ha visto un poco demasiado por encima y se te olvida…
Creo que coincido con guillem.
De redes haría falta por lo menos lo mínimo para que nadie de por sentado que lo sockets hacen magia y los inventó Aperture Labs. (En una ocasión vi un paper sobre agentes distribuidos Java para sincronizar fases en centrales eléctricas -restriccion de tiempo ~30ms- cuya única frase sobre prestaciones de las comunicaciones era «usamos UDP»). Además en teleco damos SOs 😉
Y de programación funcional, yo creo que es importante enseñar no sólo este sino también un pellizco de los paradigmas menos conocidos (programación lógica, verificación formal, etc…) aunque solo fuera para que el futuro ingeniero sea capaz de concebir que los paradigmas cambian, y que dentro de 20 años no sea de los que son incapaces de reciclarse por pura cabezonería.
Mi opinión es externa a la informática, pero coincido básicamente con gallir.
Soy físico, trabajo en investigación en el extranjero codo con codo con ingenieros mecánicos, y el otro día al ir a pedir una beca me pedían dos cartas de recomendación de profesores que me hubieran dado clase en la carrera (extraña limitación, pero ese no es el tema). La cuestión es que me costó pensar en profesores que me hubieran dado asignaturas relacionadas con el proyecto de investigación que iba a pedir.
Cuando me preguntan qué se aprende en la carrera de física respondo que lo que realmente se aprende es a resolver problemas. En mi trabajo diario no uso ni nunca he usado electromagnetismo, ni termodinámica, ni por supuesto cosas más bizarras como teoría cuántica de campos, y muy poco de las tropecientas asignaturas de matemáticas que aprobé (de teoría de grupos, geometría diferencial o análisis complejo nada de nada, pero por ejemplo sí uso bastante análisis funcional, que cuando lo estudiaba me parecía una inutilidad tremenda). Pero esas asignaturas me sirvieron como «excusas» para aprender a resolver muy diferentes problemas desde muy diferentes puntos de vista. Y con eso me gano las habichuelas, resolviendo problemas. De lo que sea. Y si este curro se me acaba, no tengo ningún miedo en irme a currar en electromagnetismo o cuántica (otra cosa es que me cojan). O incluso en hacerme un «intruso» de esos tan queridos por los trolls de tu blog. No tengo ni la décima parte de los conocimientos de tu lista (y eso que es incompleta) pero no tengo ningún miedo de aprenderlo si lo necesitara para salir del paro.
Yo le añadiría programación funcional, scheme a la vieja usanza o scala si se quiere ser más trendy y erlang si se quiere ser más práctico, hoy en día es imprescindible en la computación distribuida.
Además metería machine learning, naive Bayes por lo menos y exigiría que los alumnos montaran y tuvieran a su cargo un sistema en «producción» al menos 3 meses para que empezaran a conocer las artes malabarísticas de la profesión.
Yo creo que es una cuestión de «visión», es decir, estudias la carrera donde tienes unos conocimientos generales y es cuando empiezas a trabajar (ya sea investigando o desarrollando) cuando te vas poco a poco especializando en una materia, y claro, si ahí miras lo aprendido puedes pensar «para qué me vale la física o el cálculo», pero ¿y si en lugar de desarrollar aplicaciones desarrollas juegos, o sistemas, o hardware? Seguro que ya no piensas que la física o el cálculo no te valen de nada.
Con amigos que no terminaron los estudios universitarios y que no piensan volver critican mucho esto mismo «de qué vale tanta física, tantas matemáticas, estudiar C si lo que se utiliza es tal o cual»… por eso creo que es una cuestión de «visión» ven los cuatro árboles de su alrededor pero no alcanzan a ver el bosque ni la situación del mismo (valga el símil) 😉
Yo estudié Ingeniería Técnica en Informática de Sistemas (Universidad de Sevilla) y del listado de «cosas que se deberían estudiar en la carrera» todas ellas las estudié en materias troncales u obligatorias, menos la de «Administración de Sistemas». De administración de sistemas tuve algunas asignaturas, pero eran optativas o de libre configuración, no recuerdo bien.
Un poco irónico esto de que las asignaturas de administración de sistemas fueran optativas, puesto que mi especialidad era precisamente la de sistemas, pero bueno, ahí estaban, para quien quisiera aprovecharlas. Había una que estaba muy bien en la que se analizaba el código fuente del sistema MINIX, aunque se matriculaba poca gente por su dificultad.
Por circunstancias de la vida, hace tiempo estuve impartiendo clases en un curso para nuevos empleados en una importante tecnológica que iba sobre el cambio de paradigma, de estructurado a objetos, no era ese el título pero sí la idea del curso. Doy fe de lo complicado que era que entendieran el sentido de la orientación a objetos, sin duda motivado por la cerrajón mental que comentas. En la misma clase coincidían gente con experiencia de años programando en Java con otros que a los tres días del curso me decían que no entendían lo que era una variable de programación, pero los peores eran los que tenían experiencia, ya que programaban en Java pero de manera estructurada y era imposible cambiarles el chip; «para que si les funcionaba».
Un poquito de filosofía aplicada a la programación y a la tecnología en general no vendría nada mal, para abrir un poco las mentes.
Cuando hablo de filosofía aplicada hablo de cosas como esta
Haz clic para acceder a FilosofiaIS.pdf
Pingback: “Lo que demanda el mercado”, y el conservadurismo en la universidad | Ricardo Galli, de software libre
Aún hay esperanza, las Raspberry Pi se están vendiendo como churros! 😀
Pues a mi me parece que eso es el resultado de que Informatica no debería ser una carrera universitaria. Como mucho pues una rama de las matemáticas, y para aprender lenguajes pues un FP superior
Estoy completamente de acuerdo con todo el artículo. De hecho, Ricardo, prometo enseñárselo a alguno de mis profesores (estudio Ingeniería Informática) para comentarlo porque hay algunas cosas que si bien no se enseñan (en favor por desgracia de tecnologías concretas, muchas veces por razones de modas) yo también creo que son necesarias y alguna vez sugiero. Desde aquí te pido permiso para hacerlo.
Por cierto, un pequeño apunte, la búsqueda en árboles puede ser en altura, depth, y anchura, breadth. No conozco búsqueda de pan :P.
En el Grado en Ingeniería del Software hacemos pleno en los cinco primeros semestres, salvo el construir un sistema de ficheros (y a cambio estudiamos, por ejemplo, inteligencia artificial y programación declarativa).
De todos modos, mas que saber materia en si, lo que importan más (desde mi punto de vista) son las bases para poder aprender después con forma autodidacta.
Respecto a las matemáticas, física… Desde mi punto de vista, son fundamentos para todo tipo de ingeniero, no solo para un informático. También es verdad que, bueno, desde mi punto de vista tampoco hace falta profundizar demasiado (hasta el punto de estudiarlo un año completo).
Sea lo que sea, tenía artículo 🙂
@aitor
> No conozco búsqueda de pan
Ooops, perdón, arreglado, gracias.
Estoy de acuerdo con lo expresado en el artículo, pero me gustaría enfatizar que muchos de los algoritmos que mencionas tienen una fuerte base matemática. Y que para mi particularmente, me parece «la base», las matemáticas, la lógica, la algoritmia, tienen mucha importancia.
Como dice @moren, lo importante es resolver problemas. Las herramientas cambian con el tiempo, pero no la «física», la «lógica» ni las «mates» que hay detrás de ellas. Es más fácil adaptarse cuando uno tiene una buena base. Y como bien dice @gallir, no se trata de saber J2EE o Django o lo que este de moda, sino entender como funciona.
He tenido compañeros de trabajo que tras una ingeniería y un montón de certificaciones, ante un crash de los sistemas importante, donde la presión, el coste económico y la criticidad asustaba (sistemas de emergencia públicos), se bloqueaban, porque no era algo a lo que podían responder. Se salía de los parámetros que tenían en la cabeza y actuaban de forma ilógica y desordenada.
Mi profesor de Ampliación de Análisis Matemático decía que las matemáticas te ayudan a abrir la mente, pero no a hachazos 😉 Cuanta razón.
Creo que lo más importante que saqué de la facultad no ha sido aprender un lenguaje u otro, o algo de electrónica o de bases de datos. Salvo GNU/Linux, C y Java, poco sigo usando de las tecnologías que aprendí, empecé en 1993, mucho ha llovido. Creo que lo más importante ha sido estructurar mi mente para responder de forma lógica y metódica para enfrentarme a problemas a los que no me he enfrentado antes, aunque no conozca el SO, ni el Software ni …
Y quizá la otras dos grandes lecciones que aprendí, muy relacionadas, fueron:
No importa que tecnología te guste más. Lo que importa es resolver el problema de forma óptima. Y no óptima para ti, sino para quien tiene el problema. Los talibanismos, los fanboys, no piensan de forma clara. A veces la mejor solución para un usuario no es rodearlo de un terror tecnológico molón (aunque se facture más).
Y trabajando con un gran hombre, que no era ingeniero, pero que llevaba toda la vida en una multinacional y tenía mucha experiencia, vi que a menos que tus clientes sean informáticos, la informática es una herramienta para los demás. Has de hacerla servir para ayudarles a mejorar su negocio, y el servicio, y la disponibilidad están por encima de todo. No hay que adaptar al usuario, sino conocer como funciona, qué hace, cómo se haría mejor, y ayudarlo a hacerlo. Y tener muy presente que cuando la informática falla, o cuando se para por una migración, … eso cuesta dinero. Y que las mejoras deben argumentarse con un ROI medible.
Vaya ladrillo de comentario. Gracias por leerlo.
Tu comentario es la prueba palpable de que la ignorancia es muy atrevida. Vuelvo a incluir aquí la referencia que deja claro porqué está equivocado tu punto de vista, ya que hace mucho tiempo que la informática dejó de ser una rama de las matemáticas, porque no le quedó otra que adaptarse al mundo real
Haz clic para acceder a FilosofiaIS.pdf
Sería complicado explicarte porqué el desarrollo software va mucho más lejos que aprender lenguajes (para comprenderlo tendrías que estudiar la carrera y para entenderlo del todo algún master 😛 ) pero para hacerte una idea, a partir de la asunción de los nuevos paradigmas y sobre todo con la aparición de los patrones de diseño, el desarrollo software y por extensión los estudios de informática han comenzado a ser una verdadera ingeniería.
Eso desde un punto de vista digamos «filosófico», pero si nos metiéramos en temas de gestión de tecnologías de la información, llegarías a ser consciente de lo «inocente» (por decirlo suavemente) de tu planteamiento … para que te vaya sonando,
http://en.wikipedia.org/wiki/Corporate_governance_of_information_technology
Cada uno de los apartados en los diferentes niveles COBIT, ITIL, CMM, etc, es un mundo en si mismo. Alguno dirá, pero este conocimiento lo podría obtener un Físico o un Matemático o un Teleco con experiencia. De la misma manera que un ingeniero industrial o de caminos podría llegar a hacer el trabajo de un arquitecto … después de un proceso de adaptación.
Esta recopilación tampoco está mal 😉 http://matt.might.net/articles/what-cs-majors-should-know/
Bueno, creo que @gallir le falta dar en el meollo de la cuestión. Yo creo que el problema no es el contenido si no la forma. No es lo mismo explicar un algoritmo que ponerlo en práctica y no hablo de programarlo sino de utilizarlo para algo real. Es decir, imagínate que en vez de explicar los algoritmos que citas se hace una práctica o proyecto que implique utilizarlo y es ahí donde se le da sentido las cosas. Yo propondría que fueran 2 meses teórico y 2 meses práctico. Donde la parte práctica consistiese en que los alumnos tuviesen que aprender a resolver un problema más o menos real utilizando las herramientas que se ha explicado en los meses de teoría o en otras asignaturas, esa es la única forma que los alumnos entiendan para que sirven las cosas.
Por poner un ejemplo de tú artículo. Una vez sistemas operativos por que no hacer uno o una parte que se considere importante.
A lo mejor lo que digo no sería por ejemplo en la asignatura de sistemas Operativos I pero por que no en la II.
No sé yo creo que por ahí anda el problema.
Muy interesante, uno de mis profesores, de arquitecturas vectoriales, nos decía que él organizaría la carrera con asignaturas solo de teoría, y quizá pequeños laboratorios y asignaturas 100% prácticas donde recoger lo aprendido en varias asignaturas (haciendo grupos, SO, BBDDs, Algoritmia,Electrónica,Redes,…). Por ejemplo, tras hacer las de Sistemas Operativos, hacer uno en una práctica. Porque según él, debido al timing de las clases, no se podía explicar todo, y no se podían hacer prácticas complejas por falta de tiempo.
Prácticas así de complejas y largas, hechas en colaboración y compartiendo módulos, se parecen más al trabajo real.
Y qué más nos da saber los fundamentos o no a los que somos ingenieros? si total, después va a venir un químico, físico, gente de ADE, biólogos, historiadores, o incluso alguien que ha hecho un cursillo de programación, y nos van a levantar el puesto a cualquiera de nosotros, ya que cobran menos y, de esta forma, haciendo que nosotros tengamos que bajarnos sueldos y caché…?
Esa es la verdadera pena, que no tengamos un colegio oficial de verdad que luche por nuestras competencias, que deberían ser exclusivas de ingenieros y de gente de FP (con su correspondiente colegio claro) y que no permitiese este intrusismo salvaje que hay en nuestro sector, haciendo que nuestros sueldos sean irrisorios, que los proyectos estén mal estructurados y para nada mantenibles (ya que, precisamente, no tienen ni los fundamentos mínimos que se detallan aquí) y que no se nos valore como tendríamos que estar valorados… en una palabra: somos los tontos de las ingenierías…
Por cierto, gracias a nuestros maravillosos políticos que sepáis que ahora a cualquier intruso le pueden dar un certificado de profesionalidad, algo así como un titulito de informático, como premio a su intrusismo y al haber estado ejerciendo como tal durante «x» años…
PD: no hay nada que me repatee más que meterme en una de las muchas páginas de ofertas de trabajo y separen en las opciones «Ingenierías» de «Informática»… es que hasta aquí saben que cualquiera trabaja de lo nuestro y por eso lo separan…
Se te olvida la programación asíncrona y la programación concurrente. Hoy en día todas las tecnologías modernas son asíncronas. Realizas una llamada a un servicio y la respuesta te llega por una función de callback. Con frecuencia necesitas semáforos y zonas de exclusión para sincronizar el meollo. Yo acabé la carrera superior hace 15 años, y sin tener ni idea de javascript, gestión de oracle, programación orientada a objetos (me enseñaron smalltalk, menuda mierda), crear un site con servicios en iis, y un largo etcétera de cosas que se utilizan todos los días. Eso sí, me enseñaron un montón de mecánica de ondas, campos magnéticos, electrónica digital, integrales por el método de Laplace, ideales de un anillo abeliano, invariantes del triplete de Hoare, calculabilidad algorítmica, cálculo de límites, y un sinfín de mondongos que no he necesitado conocer en mis 15 años de profesional ni creo que vaya a utilizarlos nunca.
Otro mondongo que enseñan con inquina y que nadie utiliza son los métodos clásicos de ingeniería del software: Métrica, SSADM, Merise, etc. En la vida real, las tecnologías avanzan tan rápido y los clientes piden cambios con tanta frecuencia, que esos métodos de trabajo y documentación son ingestionables. Por eso nacieron las técnicas «ágiles» de trabajo ( http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software )
Se me hace raro que no hayas comentado nada acerca de ética profesional o de deontología. O ética hacker, si se prefiere llamarlo así. A mi me parece básico.
Yo estudié en la UJI en castellón (la ingeniería, no el grado) y hace pleno con lo que dices, además de enseñar redes (como asignatura obligatoria), teoría de autómatas y lenguajes formales, administración de sistemas linux (aquí pecan de odiar a windows o al menos es la impresión que me llevé yo). Además, también tienes asignaturas para aprender programación lógica o funcional e informática gráfica entre otras muchas cosas. Pero la cosa no está ahí, trabajamos en un entorno dónde las herramientas y lenguajes cambian constantemente por eso es importante que se sienten unas bases ya que cuando sale algo nuevo, entre que un profesor se prepara en profundidad para enseñarlo, propone una nueva asignatura y se mete en el plan de estudios (que además si tiene algún tipo de mención de calidad no lo puedes cambiar así porque sí porque la pierdes), ya han salido dos o tres promociones que se han perdido la posibilidad de realizar este tipo de asignaturas. Lo que estaría muy bien es que quizás se hicieran más talleres para aprender este tipo de tecnologías o seminarios en los que se siguieran cursos online externos a la universidad.
La verdad es que sin ser ingeniero informático ni nada parecido el artículo me ha parecido muy interesante. No se programar pero hace tiempo que es una idea que me ronda la cabeza pero no tengo claro por donde empezar, mi nivel es bajo y con todos los lenguajes que hay y las casi infinitas posibilidades no tengo claro que es lo básico por donde debería empezar a programar, alguna idea?
El único conocimiento que aprendí en la carrera y no me sirve de nada en el día a día es aquél del que no me acuerdo (por no haber prestado atención, por lo que fuera, mal hecho en todo caso).
q,
Pues yo como buen ser del baby-boom he estado trabajando desde 1986 como analista de sistemas por 25 años… sin carrera. He diseñado sistemas, implantado, y todo lo que quieras. Creo yo, que después de ganarme el pan con esto por un cuarto de siglo si que merezco que me reconozcan de algún modo mi trabajo.
El corporativismo nunca es bueno, y en mi época y de mi edad (45 años) la mayoría de los informáticos tenemos ese oscuro pasado.
Y un ingeniero en informática no debería saber ingeniería del software? UML? No lo consideráis importante?
yo soy ingeniero tecnico y no vuelvo a estudiar en mi puta vida en la universidad.
Os cuento algunas perlas.
*fisica:se veia fisica de campos magnéticos y eléctricos (sin ninguna aplicación).
* Ampliación de fisica: reflexión de la luz sin ninguna aplicación.
*sistemas operativos y adm de sistemas op que la teoria muy bien pero la practica no te enseñaban ni lo que era un active directory.
*redes que no te enseñaban ni lo que era un protocolo ni cuales (esto se veia en ampliación de redes de 4).
*Por su puesto en ninguna de programación se veia ni objeto ni nada parecido a c++, esto lo han cambiado hoy en dia ven java.
Y esos unos ejemplos de lindezas.
Cuando sales de allí sabes lo que es la vida de verdad,el problema principalmente es de los profesores se han acomodado y les interesa mas sacar el doctorado que la formación de sus alumnos total les van a pagar igual, otro problema es que ninguna de estos «profesores» han trabajado en la empresa privada y por terminal muchos no tienen ganas de formar ya que solo ven en la universidad una forma comoda de sacar el puchero
Yo creo que en realidad la queja general con el mundo universitario es que la universidad no te prepara para el mundo laboral. Te enseña a prepararte para el mundo laboral. Otra cosa es que todos tengamos la capacidad para «aprender a aprender».
Conozco mucha gente que empezó una carrera esperando tener trabajo nada más terminarla y no de cualquier cosa… ¡de analista o jefe de proyectos! Y cobrando pastones. Sí, claro. ¿Analista de qué? ¿De los porros que te fumabas para llegar a tener esas ideas?
Quizás el problema sea que no se explica a la gente lo que va a hacer en una carrera. O que no hay oferta suficiente para esa gente que busca aprender a hacer algo concreto y empleo que les reconozca ese conocimiento como es debido. Están los CFGS, sí. Pero las empresas antes contratan a un ingeniero que al mejor de los programadores en Java del ciclo formativo. Y seguramente lo que necesitan es a este último.
Pues yo creo que lo que esta mal es la empresa, no la universidad.
Tengo 39 añitos y llevo 17 años trabajando en esto de las teclas, y he hecho mas o menos de todo: programar, pruebas, instalaciones, administraciones, etc. Incluso tambien he llevado gente, aunque no es lo que mas me guste. Y he trabajado para empresas gordas de verdad, de esas que tosen y se cuadran los presidentes de gobierno, con I+D o R+D en el nombre. Y en todo ese tiempo solo una vez, una unica vez, he escrito algo de la clase de algoritmos, una funcion Hash. Y era malisima, con un 50% de colisiones (la clave era de unos 2000 caracteres y lo normal es que cambiaran menos de 10, no me despellejeis) pero aun asi mejoro el proceso la friolera de 3000 veces. Como coger el coche y llegar a trabajar (en Madrid) en uno o dos segundos. Y lo peor es que el fulano que la heredo cambio la busqueda Hash por una busqueda lineal porque no la entendia…
Y otras veces he tenido la sensacion de que me estaba pasando de listo y he dejado alguna mejora por hacer porque no es saludable que un ajeno (externo, subcontratado, mugre o como lo querais llamar) mejore demasiado lo que hace el personal propio todas las semanas.
El problema no es de la Universidad, es de la empresa, que si algo tarda compra una maquina mas gorda, y si no puede, lo mete por la noche como batch. O que se apunta a lo ultimo que este de moda en la blogocosa (una vez documente en XML porque asi le podian decir a un director que usaban XML). La universidad tiene que enseñar informatica, no C, Agile, NoSQL, PMI o TDD ni ninguna otra sigla. Si las aprendes por el camino, mejor, pero no hay que aprender Java, si no POO. Cuando sabes POO tardas una semana en aprender Java, otra en C#…
Y ademas, tiene que ser dura. El que no sea lo suficientemente vivo para adaptarse al cambio «de serie» que aprenda a ser un vivo y a adaptarse al cambio a base de trabajo, pero lo que no se puede hacer es bajar el nivel. No elitista (matricula cara) pero si dura (nivel alto) porque no hay nada malo en no ser universitario, pero da mucha pena ver a un licenciado perdido en una consola porque no funciona el raton.
Y no estaria mal que algun profesor universitario tuviera algun blog usado como referencia de algun articulo de la Wikipedia, o que fuera el primero de Google al preguntar por algun algoritmo o por alguna tecnica, o que llevara algun proyecto libre de esos que todos tenemos en la cabeza… Lo de los «papers de impacto» para un congreso en Hungria no deja de ser «nos chupamos las pollas entre nosotros en estrita intimidad».
Lo malo es que una empresa o un pais que no necesita que nadie haga funciones Hash lo unico que va a hacer es informatizar farmacias (bancos, aseguradoras o telecos solo son farmacias grandes) pero no va a hacer nada realmente importante.
Yo estudié informática, no trabajo de informática y pienso que el problema no es que te enseñen o no ciertos conocimientos técnicos sino que deben desarrollar el potencial de adquirirlos por ti mismos. La informática se puede basar en dos cosas: cursos, certificaciones o aprendizaje propio. De la carrera puedes salir con una habilidad extensa para lo primero. Para lo segundo no.
Cualquiera con un curso del INEM es programador, administrador o informático que soluciona PCs. Nadie es Ingeniero Informático.
Y a continuación, si quieren hacer una fábrica de programadores/administradores adelante, pero debería de darse una visión más global de empresa, de gestión de proyectos reales, de potenciales de comunicación que se necesitan para enfrentar cualquier entrevista de trabajo. No necesitamos crear cerebritos sino trabajadores valiosos.
Yo me quedo con que en la carrera de informática habría que estudiar más geografía e historia porque Google necesita gente para su Google Maps.
Creo que a lo que te refieres es a las tecnologías Geoespaciales, en concreto la tecnología más conocida en este entorno son los Sistemas de Información Geográfico, que es muuuucho más que Google Maps. Un mundo apasionante sin duda.
Hay buena formación para este entorno, normalmente en el formato de Master universitario
🙂 🙂 🙂
Chapó
Acabo de quedarme alucinado de lo bien que esta montado los CFGS en concreto DAI (que creo que me dijeron que ya no existe), porque cumple bastante bien los 7 puntos fuertes que comentas.
No metes ingeniería del software, patrones de diseño y frameworks, esto se pide mucho en las empresas y debería meterse más caña en la carrera.
Totalmente de acuerdo e incluiría algo más. El 99% se van a ver involucrados en proyectos, van a tener que reportar a un analista que a su vez va a reportar a un jefe de proyecto, que a su vez va a reportar a un gerente, por lo que un conocimiento mínimo de la gestión de proyectos es indispensable. Si se entiende lo que es el avance de un proyecto, se puede entender porqué te piden lo que te piden en el momento que te lo piden … absolutamente fundamental.
Si se entendiera por todo el equipo como se integra la gestión de proyectos con las metodologías de proyectos software (Métrica, ¿Ágil? … también, no le queda otra), los proyectos irían mucho mejor, sin duda.
Por cierto, he estado pegándome el finde con un parseador y no estaría mal que los alumnos salieran de la carrera habiendo implementado al menos uno con lex y bison(yacc). Y las mencionas, pero creo que las expresiones regulares deberían ser a la informática como la formulación a la química.
Lo siento Ricardo, pero temo estar en total desacuerdo contigo, o acaso a un Arquitecto le enseñan tecnología de los materiales o dinámica de fluidos para comprender el diámetro necesario para la instalación de la calefacción?
Como bien todos sabemos, con que les enseñen Autocad, y cuales son las revistas de moda en Arquitectura, se convierten en arquitectos de «calidad»
// MODE ironic off (por si alguno no se había dado cuenta) //
creo que el problema se reduce a la percepción que muchos tienen de «los informáticos», que somo «arregla PCs» (y ahora «arregla mobiles», cuando no «arregla cualquier cosa con botones») mientras soñamos con ser «Bill Gates» o «Larry Pages». Y esto inevitablemente llega a ser el pensamiento de algunos «ingenieros» de la industria e incluso dentro de la universidad.
vamos que lo mismo que si llamas a tu amigo arquitecto a que te limpie el sifon del fregadero mientras piensas que su sueño es ser como Gustave Eiffel o Santiago Caratrava
Estoy bastante de acuerdo con el artículo, principalmente la Universidad tiene que sentar las bases de un ingeniero informático, no hacer un hipster de tecnologías de moda.
Una buena base es lo que nos da el soporte para ser autodidactas y aprender por nuestra cuenta lo necesario en cada momento, lo que realmente nos hace ingenieros no es saber programar con el último framework de moda, si no nuestra capacidad de adaptarnos.
En cuanto al tema de los puntos interesantes que se deberían tocar, me gustaría comentar que en mi caso, aunque en la universidad (Deusto) si que hemos utilizado Linux en varias ocasiones, al igual que en casi todas las prácticas te dan todo taaaan comido y mascado que parecen ejercicios de «fill in the gaps», y así no es como se aprende. A veces el problema no solo está en el temario si no en como se enseña.
En mi experiencia personal desde que empezamos a programar comencé en Linux por que me interesaba aprender a programar y compilar mis programas mas allá de la compilación con un IDE predefinido (y ciertamente en Linux es bastante cómodo y educativo).