Portada
mis comunidades
otras secciones
#1:
Tampoco es culpa de las “empresas” o el “mercado”, desde la propia universidad solemos transmitir el mensaje equivocado:
Un ingeniero informático no programa, dirige proyectos
Ese mantra lo oí muchas veces y los alumnos lo escuchan frecuentemente en clases. El error es múltiple, por un lado transmitimos la idea que un ingeniero graduado sabe todo lo necesario, que no hace falta experiencia en programación, y que programar es de pringaos.
joder que gran verdad, muchas veces ese es el mensaje que se da (o daba) cuando cursabas ingeniería informática.
Un ingeniero informático no programa, dirige proyectos
Ese mantra lo oí muchas veces y los alumnos lo escuchan frecuentemente en clases. El error es múltiple, por un lado transmitimos la idea que un ingeniero graduado sabe todo lo necesario, que no hace falta experiencia en programación, y que programar es de pringaos.
joder que gran verdad, muchas veces ese es el mensaje que se da (o daba) cuando cursabas ingeniería informática.
#37:
El poner el título de ingeniero a los informáticos ha hecho más mal que bien por esto que cuenta Galli, los informáticos deberían de ser ante todo programadores y no avergonzarse de ello ya que es una de las profesiones más exigentes, apasionantes y poderosas que hay hoy en el mundo.
#3 Yo no estoy de acuerdo, para hacer aplicaciones sencillas o las partes simples de una aplicación web, de gestión o juegos a un nivel básico puedes tirar. Pero cuando ya empiezas a manejar grandes volúmenes de datos (data mining), o manejar datos complejos (juegos, aplicaciones de ingeniería) ya requieren conocimientos de teoría de computación, algoritmos, estadística, inteligencia artificial, álgebra y cálculo.
La base matemática es muy difícil cogerla sin pasar por la universidad y al fin y al cabo los ordenadores son máquinas de cómputo. Si bien los estudios de informática en España no son especialmente buenos ya que la universidad española está anclada en el siglo XIX en muchas cosas, si aportan cosas valiosas desde el punto de vista teórico.
#3 Yo no estoy de acuerdo, para hacer aplicaciones sencillas o las partes simples de una aplicación web, de gestión o juegos a un nivel básico puedes tirar. Pero cuando ya empiezas a manejar grandes volúmenes de datos (data mining), o manejar datos complejos (juegos, aplicaciones de ingeniería) ya requieren conocimientos de teoría de computación, algoritmos, estadística, inteligencia artificial, álgebra y cálculo.
La base matemática es muy difícil cogerla sin pasar por la universidad y al fin y al cabo los ordenadores son máquinas de cómputo. Si bien los estudios de informática en España no son especialmente buenos ya que la universidad española está anclada en el siglo XIX en muchas cosas, si aportan cosas valiosas desde el punto de vista teórico.
#26:
He tenido el placer de programar drivers tanto para linux como para windows, sobre todo drivers de red. Y bueno, creo que hay diferencias sustanciales entre uno y otro que puede que compararlos en igualdad de condiciones no sea correcto.
No sé cuál de los dos funciona más rápido, pero Microsoft tiene un handicap muy grande: Tiene que integrarse con miles de 3rd partys que no tienen acceso a su código, por lo que tienen que "heredar" todo el legacy (sino sólo hay que ver cuánto les está costando erradicar una mierda de API como TDI).
Otra cosa es, que algunas nuevas APIs de red, como WPF sean una castaña, y que al lado de NDIS palidezcan, es decir, en el kernel de Windows te puedes encontrar oro molido y verdaderas lacras, esto puede ser fruto de la pérdida de talento que comentan en el artículo.
También es verdad, que programar drivers en Windows es bastante más difícil que en linux (al menos hasta donde yo lo he visto), la gestión de IRP's al principio es complicada, y no saber cómo funcionan "realmente" las cosas no ayuda.
Ahora bien, Linux ni de lejos tiene unas APIs tan serias como las de Windows (como comenta #11), y éstas cambian tanto de versión en versión que la programación también se hace complicada, a veces es tan complicado dar servicio a varias versiones del kernel que escribir el propio módulo en sí.
Linux no tiene nada ni remotamente parecido a WinDbg, ni análisis de dumps, ni un sistema de calidad como WHQL para la integración de drivers de terceros, por lo que muchas veces se hacen las cosas un poco a ciegas o confiando en que todo "vaya bien".
Pero bueno, ya he soltado la chapa.
Por cierto, eso que habla de proyect managers, en mi opinión es un subproducto de aplicar Scrum (Microsoft trabaja con esta metodología), donde los proyect managers pueden ser pequeños "tiranos" que lo primero necesitan justificarse a sí mismos, y que todo lo que venga de fuera de su equipo se puede considerar una "intromisión".
No sé cuál de los dos funciona más rápido, pero Microsoft tiene un handicap muy grande: Tiene que integrarse con miles de 3rd partys que no tienen acceso a su código, por lo que tienen que "heredar" todo el legacy (sino sólo hay que ver cuánto les está costando erradicar una mierda de API como TDI).
Otra cosa es, que algunas nuevas APIs de red, como WPF sean una castaña, y que al lado de NDIS palidezcan, es decir, en el kernel de Windows te puedes encontrar oro molido y verdaderas lacras, esto puede ser fruto de la pérdida de talento que comentan en el artículo.
También es verdad, que programar drivers en Windows es bastante más difícil que en linux (al menos hasta donde yo lo he visto), la gestión de IRP's al principio es complicada, y no saber cómo funcionan "realmente" las cosas no ayuda.
Ahora bien, Linux ni de lejos tiene unas APIs tan serias como las de Windows (como comenta #11), y éstas cambian tanto de versión en versión que la programación también se hace complicada, a veces es tan complicado dar servicio a varias versiones del kernel que escribir el propio módulo en sí.
Linux no tiene nada ni remotamente parecido a WinDbg, ni análisis de dumps, ni un sistema de calidad como WHQL para la integración de drivers de terceros, por lo que muchas veces se hacen las cosas un poco a ciegas o confiando en que todo "vaya bien".
Pero bueno, ya he soltado la chapa.
Por cierto, eso que habla de proyect managers, en mi opinión es un subproducto de aplicar Scrum (Microsoft trabaja con esta metodología), donde los proyect managers pueden ser pequeños "tiranos" que lo primero necesitan justificarse a sí mismos, y que todo lo que venga de fuera de su equipo se puede considerar una "intromisión".
#3:
Debemos empezar a esforzarnos en formar a profesionales cuyo objetivo sean jubilarse como programadores
Realmente ya existe el DAI (FP de Grado Superior, Desarrollo de Aplicaciones Informáticas) donde la programación es mucha mas completa que lo que se da en la Ingeniería. Sino fuera por el síndrome de la titulitis de este país recomendaría antes la FP que perder 5 años de carrera si tu vocación es programar.
Realmente ya existe el DAI (FP de Grado Superior, Desarrollo de Aplicaciones Informáticas) donde la programación es mucha mas completa que lo que se da en la Ingeniería. Sino fuera por el síndrome de la titulitis de este país recomendaría antes la FP que perder 5 años de carrera si tu vocación es programar.
#29:
Como se organizan las distintas grandes empresas tecnológicos.
Las guerras internas de microsoft y la nula colaboración entre equipos internos son legendarias.
http://www.bonkersworld.net/organizational-charts/
#28 Espero que vieras programación funcional y programación lógica. Un ingeniero debería conocer los distintos paradigmas y ser capaz de programar basicamente en todos ellos. Al menos los cuatro mayores.
Las guerras internas de microsoft y la nula colaboración entre equipos internos son legendarias.
http://www.bonkersworld.net/organizational-charts/
#28 Espero que vieras programación funcional y programación lógica. Un ingeniero debería conocer los distintos paradigmas y ser capaz de programar basicamente en todos ellos. Al menos los cuatro mayores.
#45:
Desgraciadamente, tal y como indica GalliR, los profesionales de la informática acabamos siendo desplazados, a veces incluso en contra de nuestra voluntad, a puestos "de mayor responsabilidad"... y hablo por experiencia propia. Nunca he sido tan feliz como cuándo era un picacódigo; ahora el 90% de mi tiempo es pelea con distribuídores/clientes en preventa y el 10% (siendo optimista) temas técnicos (a veces si "cazo" una consulta ni la derivo al soporte o a programación, la atiendo yo sólo por darme ese gusto y sentirme todavía un técnico).
Y todavía no he llegado a los 40. Mi sueldo ha mejorado, tengo despacho, tengo ventana, tengo vistas... Pero no siento ese hormigueo
Y todavía no he llegado a los 40. Mi sueldo ha mejorado, tengo despacho, tengo ventana, tengo vistas... Pero no siento ese hormigueo
#20:
#1 Bueno, a mí no me lo dieron nunca y ya estudié hace unos cuantos años. Luego, cuando llegas al entorno laboral sí que te lo dan algunos, sobre todo los jefes de proyecto que no han programado una línea en su vida. Pero cuando adquieres experiencia de desarrollador es cuando te das cuenta de que el ingeniero debe programar y ese es su fin. Que luego también dirija proyectos, pues muy bien. Pero si no escribe código (proceso de diseño, no de construcción, por cierto) no será un buen ingeniero informático nunca.
#9 Cierto es que cosas específicas no se dan en las carreras, pero a mí me enseñaron a aprender informática, lejos de aprender a programar en un lenguaje determinado. Quizás también sea mucho la actitud de la persona, si le gusta, si quiere aprender o si sólo busca trabajo.
#9 Cierto es que cosas específicas no se dan en las carreras, pero a mí me enseñaron a aprender informática, lejos de aprender a programar en un lenguaje determinado. Quizás también sea mucho la actitud de la persona, si le gusta, si quiere aprender o si sólo busca trabajo.
Comentarios
Tampoco es culpa de las “empresas” o el “mercado”, desde la propia universidad solemos transmitir el mensaje equivocado:
Un ingeniero informático no programa, dirige proyectos
Ese mantra lo oí muchas veces y los alumnos lo escuchan frecuentemente en clases. El error es múltiple, por un lado transmitimos la idea que un ingeniero graduado sabe todo lo necesario, que no hace falta experiencia en programación, y que programar es de pringaos.
joder que gran verdad, muchas veces ese es el mensaje que se da (o daba) cuando cursabas ingeniería informática.
#1 Bueno, a mí no me lo dieron nunca y ya estudié hace unos cuantos años. Luego, cuando llegas al entorno laboral sí que te lo dan algunos, sobre todo los jefes de proyecto que no han programado una línea en su vida. Pero cuando adquieres experiencia de desarrollador es cuando te das cuenta de que el ingeniero debe programar y ese es su fin. Que luego también dirija proyectos, pues muy bien. Pero si no escribe código (proceso de diseño, no de construcción, por cierto) no será un buen ingeniero informático nunca.
#9 Cierto es que cosas específicas no se dan en las carreras, pero a mí me enseñaron a aprender informática, lejos de aprender a programar en un lenguaje determinado. Quizás también sea mucho la actitud de la persona, si le gusta, si quiere aprender o si sólo busca trabajo.
#20 Entonces a mi me lo dieron por los dos
#1 A mí me da la sencación a veces que, desde algunos de los movimientos "anti intrusismo" y de "colegiados informáticos", es lo que se pretende transmitir...
#1 Eso le pasa a una amiga mía de cara a ascender, que cuando se asciende, uno se hace director de proyectos y ella quiere seguir programando, además que si una vez que tiene mucha experiencia, si solo programan los novatos pues no se benefician de su experiencia programando. En educación es similar, un ascenso de profesor suele ser hacerte director de estudios o director de la escuela, pero no es lo mismo que trabajar de profesor.
#1 Asi es. CUanto gilipollas hay que se cree que es ingeniero, que eso de programar es de fracasados.
Luego se dan con un muro en la cara cuando espabilan, si lo hacen.
#2 Eso ya lo sabemos todos los que trabajamos en esto, que solo interesa mejorar si hay pasta o una subvencion de por medio, sino pasan de todo. El programador nunca puede ascender, es mano de obra barata. Eso si, con los años deberas de conocer una docena de lenguajes de programacion, todos ellos ser un "esperto".
Debemos empezar a esforzarnos en formar a profesionales cuyo objetivo sean jubilarse como programadores
Realmente ya existe el DAI (FP de Grado Superior, Desarrollo de Aplicaciones Informáticas) donde la programación es mucha mas completa que lo que se da en la Ingeniería. Sino fuera por el síndrome de la titulitis de este país recomendaría antes la FP que perder 5 años de carrera si tu vocación es programar.
#3 En mi opinión, y fuera de la titulitis, creo que hace falta mucho mas de lo que se da en DAI para ser un buen ingeniero de software, claro que lo que falta, muchas veces tampoco se encuentra en la carreras.
#9 Yo me refiero a los programadores senior (muy distintos de los gestores de los Ingenieros), para ellos una carrera de Ingeniera Informática es una perdida de tiempo y dinero existiendo el DAI, el cual es la formación mas especializada en la programación que se pueda encontrar sin meterse en Masters o Diplomas (los cuales exigen dinero o un milagro para que te concedan becas).
#13 Yo también hablo de los programadores (senior simplemente se refiere a su experiencia laboral). Creo que el DAI es insuficiente en cuanto a contenidos, sin mas.
#14 Ein?
#16 En mi cabeza está bastante claro. A ver si me explico..
En #9 tú decías, o entendí, que tanto los de DAI como los de la ingeniería aportan cosas buenas. De hecho es como yo lo veo.
Y dado que los proyectos de software suelen ser proyectos de bastantes personas, existe el trabajo en equipo. Y no hacen falta ni más DAI ni más ingenieros. Sino ambos.
Si querías decir que ambos carecen de experiencia. Pues sí, aunque no deja de ser una obviedad.
#17 En mi comentario contestaba a #3. No creo que para ser ingeniero software baste con el DAI, pero la alternativa que es la carrera, tampoco me parece especialmente adecuada. Conclusión, en España no existen carreras profesionales dentro de la ingeniería de software.
Lo que tu comentas del trabajo en equipo esta muy bien, pero la programación, por mucho que se empeñen, no se puede modularizar como una obra de aruitectura, los limites no estan tan claro, y por ello no existe realmente la figura del DAI y el ingniero software.
#16 Hombre, si los comparas con todos los contenidos de la Ingeniería es obvio que en cantidad no es el mismo, pero hablamos de un puesto de programador (que no ingeniero). Como contenidos de programación en la carrera no solía pasar de los 2 años con 3 o 4 horas como mucho a la semana (en mi época claro), en cambio en el DAI superaban la docena de horas a la semana en 3 o 4 lenguajes como mínimo y de propina con practicas laborales obligatorias (aunque siendo becario a documentar código).
#23 Es algo mas que escribir lineas de código, que a mi en la Ingeniería ni siquiera me enseñaron a programar con orientación a objetos y sino fuera por el antiguo DAI seria un autentico ceporro programando (cuando desarrollas software de miles de lineas de código hay que hacerlo bien desde la base).
Como se organizan las distintas grandes empresas tecnológicos.
Las guerras internas de microsoft y la nula colaboración entre equipos internos son legendarias.
http://www.bonkersworld.net/organizational-charts/
#28 Espero que vieras programación funcional y programación lógica. Un ingeniero debería conocer los distintos paradigmas y ser capaz de programar basicamente en todos ellos. Al menos los cuatro mayores.
#28 Por si acaso, mi comentario anterior no va con la intención de menospreciar a nadie que haya hecho DAI y me parece que esa experiencia tuya es más bien particular y se debe a que alguien no hizo lo que debería (tu, tus profesores, tu universidad, ni idea). Lamentablemente volviendo a mi comentario, en una ingeniería te dan una base teórica muy fuerte y se asume que pondrás la parte práctica (¿con qué tiempo?)
También es consecuencia de lo que dice #29, damos muchas cosas, pero a lo mejor no profundizamos demasiado en el aspecto práctico. Yo recu
#38 Envié el comentario sin querer... decía que yo recuerdo que en el primer año, la asignatura de programación fue una criba. Algo que se entiende si se tienen en cuenta que en ingeniería te explican cosas como las instrucciones básicas, las de selección, y las iterativas en una semana (4horas), y luego se hace una práctica sobre ello. Y sin embargo alguien de DAI te dice que ellos estuvieron semanas haciendo pequeñas prácticas cada vez más complejas sobre ese tipo de instrucciones. En definitiva, nosotros dimos en un cuatrimestre lo que ellos dieron en todo un año, eso sí, no les preguntes sobre recursividad o punteros, que muchas veces les duele la cabeza...
#42 Yo hice hace años DAI, estoy terminando ahora la ingenieria, y la verdad que no sé si fue donde hice DAI lo hicieron muy bien pero realmente en la carrera lo único nuevo fueron más matemáticas. Y no me daban mareos si veia punteroso recursividad, te lo aseguro.
#60 Yo creo que tomas mi comentario como si hablara sin saber del tema, si te digo eso es porque conozco muchos casos, porque es habitual encontrarse con gente que viene de ciclos en la carrera. Seguramente eso hable mejor de ti, sobre todo si luego decidiste sacarte la ingeniería y lo conseguiste, sobre tus compañeros y sobre otras personas mantengo mi comentario.
Y por si acaso, también sé de casos que no se marean, pero son casos, y en esos casos se suele más de mérito personal que de otra cosa. Y por cierto, si hiciste la carrera y sólo sacaste más matemáticas, perdiste el tiempo y lo desaprovechaste. Otra cosa es que luego en la práctica, no todo lo que se de vaya a servir, por cosas como las que se mencionan en otros comentarios.
#29 A mí me mola la organicación de Valve (pág 5) -> http://media.steampowered.com/apps/valve/Valve_Handbook_LowRes.pdf
#28 Lo siento pero no puedo separar el puesto de programador del de ingniero. A mi me da igual si hizo una carrera o no, pero para mi no existe eso que la gente llama programador, una especie de entelequia a la que le pasan un diseño y solo implementa. Eso no existe.
#30 Por gente como tu es bastante normal que los programadores que puedan tiendan a emigrar o simplemente ir por libres. Tranquilo, no eres el único que ve a los programadores como un albañil y luego se preguntan como el programa tiene bugs a punta pala cuando el Ingeniero (o el comercial de turno) tiene antojos que no se producirían en caso de entender la programación de software.
Por relacionarlo con la noticia, "eres de Microsoft" mientras yo "soy de Linux". Así va España.
#33 Hostia, no sabia que me explicaba tan mal. Precisamente lo que he dicho es que no existe esa analogia entre la construcción y el software. En fin.
La comparación MS - Linux me ha dejado con el culo torcido
Por curiosidad, estudias o trabajas?
#31 Un ingeniero es aquel que ingenia soluciones a problemas.
El que optimiza los recursos es un gestor, y normalmente, aunque sean ingenieros, los gestores no trabajan de ingenieros sino de gestores.
Son dos cosas diferentes.
#30 Estoy contigo.
#28 Hay muchos niveles en lo que a programación respecta. Y lo que dices de las horas, en FP en general hay muchas más horas de clase. La diferencia está en la cantidad de horas que pasas chapando o practicando en la biblioteca o en casa. Y claro que puede haber gente que saque la carrera de mala manera y sin tener ni idea, pero lo mismo sucede con la FP, pero un buen FP sólo está preparado para implementar cosas relativamente mecánicas (otra cosa es lo que aprenda luego).
#3 #13 Hace poco pusieron en marcha nuevos planes de estudio en ese aspecto (DAW, DAM), habría que ver qué dan ahí, que no lo sé, por experiencias cercanas sé que lo que se da en el DAI basta para programar, es decir, escribir líneas de código con algún sentido, aunque tienen en su favor que se práctica mucho.
Lo demás se deja a la intuición, y es cierto que mucha práctica la agudiza, pero a veces hace falta más que eso para saber claramente que estás haciendo. Luego ya es otro tema si eso en muchos casos hace falta, por lo menos en lo que son las consultoras, no.
PS: http://xkcd.com/664/
#9 Claro. Por eso el ser humano inventó el trabajo en equipo antes que la escritura.
#3 He intentado buscar lo que dices, y al menos en Andalucia lo más parecido que he encontrado es esto: http://www.fp-informatica.es/dam/
¿Es lo mismo pero con otro nombre?
#3 #15 existía, ahora se dividió en dos en DAW ( Desarrollo de Aplicaciones Web ) y DAM ( Desarrollo de Aplicaciones Multiplataforma )
#19 ¿Lo que antes hacías en 2 años, ahora lo haces en 4? De todas maneras solo me interesa las aplicaciones de escritorio, así que sería coger el DAM.
#21 No es que se haga en 4, sino que se especializa en web o multiplataforma, pero igualmente podría hacerse las 2 en 3 años, ya que muchas materias serían convalidables entre los dos cursos
El poner el título de ingeniero a los informáticos ha hecho más mal que bien por esto que cuenta Galli, los informáticos deberían de ser ante todo programadores y no avergonzarse de ello ya que es una de las profesiones más exigentes, apasionantes y poderosas que hay hoy en el mundo.
#3 Yo no estoy de acuerdo, para hacer aplicaciones sencillas o las partes simples de una aplicación web, de gestión o juegos a un nivel básico puedes tirar. Pero cuando ya empiezas a manejar grandes volúmenes de datos (data mining), o manejar datos complejos (juegos, aplicaciones de ingeniería) ya requieren conocimientos de teoría de computación, algoritmos, estadística, inteligencia artificial, álgebra y cálculo.
La base matemática es muy difícil cogerla sin pasar por la universidad y al fin y al cabo los ordenadores son máquinas de cómputo. Si bien los estudios de informática en España no son especialmente buenos ya que la universidad española está anclada en el siglo XIX en muchas cosas, si aportan cosas valiosas desde el punto de vista teórico.
#3 No.
#3 ni de coña.
#3 Pues yo no estoy nada de acuerdo con lo que dices de que siempre sea preferible contratar a un FP.
En mi opinión, por la gente que he conocido que ha estudiado FP (tuve varios compañeros en la facultad que antes habían hecho una FP de informática y también he tenido algunos compañeros de trabajo novatos que venían de la FP).
La impresión que he sacado de esos compañeros es que en la FP les enseñan muchos lenguajes de programación, más que en la ingeniería (al menos en la que yo he hecho que es la ingeniería técnica en informática de gestión) y posiblemente con mayor profundidad, pero no les enseñan nada o casi nada de patrones de diseño, por ejemplo, muchos de ellos están acostumbrados a mezclar el código de la presentación con el del funcionamiento de la aplicación (les hablas del patrón MVC y no saben lo que es), tampoco han oído hablar de "patrones" tan simples como "bajo acoplamiento" y "alta cohesión" (GRAPS en general): les he visto crear funciones que supuestamente realizan una determinada tarea y, ya de paso, realizan un montón de tareas más que no vienen a cuento (osea, que la cohesión a tomar por saco) y lo mismo con el acoplamiento: objetos que necesitan obtener algún dato en concreto de otros objetos a los que acceden a través de un objeto intermedio y que en vez de recibir el dato a través, por ejemplo, de un simple String desde el objeto intermedio, reciben el objeto que tiene el dato creando un acoplamiento innecesario. También recuerdo una ocasión en la que para desactivar un grupo de botones en una página web a un tipo se le ocurrió que en vez de utilizar el atributo "disabled" de dichos botones era mejor desactivar los botones situando una capa transparente encima de los botones, con lo cual era imposible pulsar los botones que estaban debajo aunque eran visibles y su aspecto era el de un botón activo. Lo peor es que la mayoría de esos errores también los cometía un chaval que decía haber terminado la FP con una media de sobresaliente (vamos, que no era uno que había aprobado por los pelos que posiblemente aunque le hubieran enseñado muchos de esos patrones no habría aprendido a utilizarlos).
Así que mi conclusión es que pueden conocer muchos lenguajes de programación y en mayor profundidad que un ingeniero pero de nociones de diseño andan bastante escasos. Al menos yo para situaciones en las que el programador tenga que tomar decisiones de diseño preferiría contratar al menos a algunos ingenieros, aunque algunos también meten la pata hasta el fondo pero al menos la base de conocimientos se supone que la tienen; y si el diseño se ha realizado con un gran nivel de detalle (llegando a detallar las funciones a implementar y lo que deben hacer) posiblemente preferiría gente de FP que sólo se limiten a plasmar en código el diseño.
Aunque lo mejor en cualquier caso sería contratar a alguien que, sea ingeniero o FP, o bien te enseñe algo que haya programado o bien pase una pequeña prueba de forma que puedas comprobar que posee algunos conocimientos básicos sobre patrones (GRASP, MVC,...).
#61 Alguien dijo una vez algo así como que la gente asciende mientras que demuestran ser competentes en su puesto y se quedan estancados en el puesto para el que demuestran ser unos incompetentes y de ahí que en los puestos de "alta dirección" estuvieran repletos de incompetentes (¿alguien recuerda exactamente como era la frase?).
#64 Yo tambien lo habia oido y tampoco lo recordaba exactamente, google me ha llevado a la wikipedia
http://es.wikipedia.org/wiki/Principio_de_Peter
Y una variación que trata sobre lo mismo
http://es.wikipedia.org/wiki/Principio_de_Dilbert
#65 Gracias por el dato.
#64 Yo estudie ambos (ya hace unos cuantos años) y con el paso de años he visto empresas rechazar ingenieros recién licenciados en contra de los FP por que es salen muy verdes para el mundo laboral (y francamente las empresas mas competentes en las que he trabajado).
No voy a extrapolar mi formación al resto de centros de España, pero en mi carrera me formaron en programación en bloque (nada de objetos) usando Ensamblador donde el profesor nos examinaba en papel por que tenia la paranoia de que algún día deberíamos construir programas sobre papel. Di bastante teoría para comprender aspectos básicos de la programación, pero lo que se dice programar delante un ordenador, un autentico desastre. Luego incluso en una empresa ya hace unos años recibimos un recién licenciado universitario que ni siquiera sabia que era compilar, había recibido toda su formación de programación en papel (no es que fuera tonto ni mucho menos, pero perdimos muchísimas horas formandole). En cambio con cualquiera de FP en cuanto asimilaba el código del proyecto no había que llevarle de la mano, quizás sea por que siempre he trabajado en proyectos relativamente pequeños o por que simplemente eran superdotados, pero me parece lamentable la actitud de desacreditarlos cuando son igual de competentes.
También estoy bastante cansado de los ingenieros recién licenciados defendiendo su carrera como si les fuera la vida en ello (no va por ti), te sacan teoría que esta al alcance de cualquiera en Internet. Anda que no habré tenido que repasar cosas de la carrera y FP por que los años pasan y se olvidan, o simplemente aprender cosas nuevas que no se dan en ambas. La formación de programación no se acaba con la carrera, pero para la mayoría de ingenieros en cuanto les dan el titulo se acaba ahí.
PD: Y he visto autenticas burradas de códigos de ingenieros supuestamente sobresalientes, siempre recordare uno que creo 50 Ifs pudiendo hacer una clase o una función, me llego al alma.
#66 La formación de programación no se acaba con la carrera, pero para la mayoría de ingenieros en cuanto les dan el titulo se acaba ahí.
Sustituye "ingeniero informático" por la profesión que quieras, y funciona exactamente igual (sí, hasta con médicos y cosas así). En realidad, es pura estadística. La mayoría de gente es mediocre, y sólo hay una minoría excepcional que destaca sobre los demás.
#66 jajaja, muy bueno lo de los ifs.
Y tienes razón en que en programación siempre hay que seguir formándose, bien porque cambie el lenguaje, el framework,..., o simplemente porque necesites ampliar/refrescar los conocimientos que ya tienes. Supongo que si realmente tienes vocación por este trabajo lo harás porque es lo que te gusta y si simplemente te has metido en el mundillo porque es lo que pensaste que tenía salida en su momento no, independientemente de si estudiaste un FP, una ingeniería o hiciste un cursillo de 3 meses.
En lo de que los ingenieros salen verdes, no te diré que no, en la ingeniería te dan una base de conocimientos muy amplia: lenguajes de programación, análisis y diseño de aplicaciones, algoritmos, redes, sistemas operativos,... pero con poca profundidad. En FP, por lo que yo he visto, diría que la base de conocimientos se limita más a lenguajes de programación que se dan con mayor profundidad y en mayor número y el resto no se da o se da con mucha menor profundidad aún que en la ingeniería.
Lo de ingenieros que no saben lo que es compilar me sorprende, y lo de recibir toda la formación en papel mucho más, aunque supongo que habrá Universidades para todo (y lo mismo se podría aplicar para los FP, que he visto alguno, aunque no relacionado con la informática, en el que prácticamente dan el título a cambio de ocupar el asiento). En mi primer año de ingeniería se daba programación estructurada en C en el primer cuatrimestre y POO con C++ en el segundo incluyendo construcción de makefiles basados en macros (ahí comenzando con lo fácil: punteros, gestión de memoria dinámica, makefiles y demás mientras que en otras Universidades según tengo entendido se comienza con Simula, Visual Basic o cosas por el estilo), y el resto de años programación en Java y algo de otros lenguajes (ensamblador, PHP, Python,..), además de análisis y diseño de aplicaciones, bases de datos relacionales, matemáticas, algoritmos, redes, electrónica y sistemas operativos repartidos por los 3 años de carrera.
Lo de las burradas de ingenieros, también he visto alguna, y también he caído en alguna, pero por olvido o descuido más que por falta de los conocimientos necesarios para no caer en el error (en ocasiones es lo que tienen las prisas que se acaba metiendo la pata haciendo lo primero que se te ocurre o aplicando parche tras parche cuando tomándote algo de tiempo en pensar lo que haces lo harías mucho mejor).
#69 Lo que sí he conocido, y es bastante habitual, es gente que va por su tercer año y no tiene ni idea de como depurar el código. De todas formas, más que darlos en mayor profundidad, lo que yo he visto es que simplemente tienen más práctica. También por lo general he visto que dar dos o tres lenguajes.
A mi en su momento, como dije antes, me explicaron las instrucciones básicas, de selección, e iteración en una semana, dos clases de dos horas. Realmente no hace falta más, es básicamente sintaxis, pero eso no te da una idea de como pensar y resolver un problema usando if, whiles, fors. A eso me refiero con tener mejor intuición.
Por ese entonces pedí apuntes de programación a compañeros que venían de una FP, y más que apuntes, me pasaron listados y listados de ejercicios y prácticas que hicieron. Ni teoría (que algo sí había) de paradigmas de programación, ni de invariantes, ni precondiciones y postcondiciones, ni complejidad. Simplemente ejercicios, y la verdad es que me ayudaron bastante.
Saber la sintaxis de un while, no te ayuda a pensar en todas las posibilidades que tiene, y eso es a mi juicio la mayor diferencia. En una ingeniería aunque te manden muchas prácticas, simplemente son "muchas" relativamente al tiempo que tienes, el que practiques mucho lo que sabes se deja a cargo del alumno.
#72 En lo de tener más práctica y no saber depurar el código también te tengo que dar la razón.
Al menos en mi caso durante la carrera era bastante común programar únicamente con un editor de texto con resaltado de sintaxis y la depuración consistía en imprimir texto en la consola y/o ver los logs de la aplicación. Lo de los IDEs y los depuradores se da al final y bastante por encima y tampoco son obligatorios en la mayoría de los casos por lo que puedes terminar la carrera prácticamente sin haberlos utilizado.
Y en lo de la práctica, en la carrera se practica entregando algunos proyectos que el profesor simplemente evalúa, sin detenerse en comentar los errores cometidos (en ocasiones lo hacen, pero de forma global, destacando los errores más habituales pero, al menos en mi caso, nunca lo hicieron alumno por alumno) por lo que si quieres aprender realmente tienes que poner esfuerzo de tu parte y la práctica sólo sirve para evaluar ese esfuerzo. Supongo que a diferencia de la FP en la que te lo dan todo bastante mascado en la carrera el profesor se limita a darte una base teórica con algunos ejemplos básicos y luego el alumno tiene que poner de su parte para aprender a llevar la teoría a la práctica (que en el fondo es positivo porque te ayuda a aprender a investigar por tu cuenta y a resolver problemas que nunca antes se te habían planteado, pero exige un esfuerzo voluntario que no todo el mundo está dispuesto a realizar).
#69 Te hablo de casi hace una década con la tontería, que los años no perdonan. Quiero creer que las universidades se ponen al día, pero basta con ver como la FP se adapta mas rápido dividiendo los grados. Me sigue pareciendo surrealista como en un campo tan grande como la informática las universidades solo ofrezcan una carrera como tal, hace décadas que debería haber especializaciones obligatorias (como medicina) o una división de carreras por que cuando yo estudie la ingeniería no te especializaba en absolutamente nada.
#72 Salvo que haya cambiado con los años drásticamente, el DAI exige una tonelada de teoría "de papel" los primeros trimestres. Después pasas a aplicarla junto a mas teoría a través de ejercicios usando ordenadores (una herramienta que en mi universidad era como herejía) a través de varios lenguajes que son base de otros muchos (como C++ o Java). Aprendes a desarrollar todas las etapas de un proyecto de software como lo harías en cualquier empresa, quizás fuera necesaria mayor profundidad por que hablamos de solamente 2 años, pero salen perfectamente formados para integrarse en el mundo laboral (obviamente siempre puede tocar idiotas).
La practica con la programación en ordenadores es muy necesaria y no es obligatoria en la universidad, lo cual siempre me ha parecido un grave error y con el paso de los años me hace reafirmarlo viendo como los procedentes de la FP son mas autosuficientes que los universitarios. A fin de cuentas una empresa no esta para seguir formando, debes ganarte el sueldo por muy bajo que sea y si no sabes utilizar una herramienta de trabajo debería ser despido inmediato. Pero los universitarios tienen suerte en este país y con un papel sellado ya tienes sueldo garantizado en las cárnicas (conocidas mundialmente por su calidad de software...).
PD: En mi centro de FP los exámenes de programación llevaban como poco 4 horas para crear el programa que pedían, y eso incluía desde los diagramas hasta los tediosos comentarios del código (eso no lo haces a base de solo practica que digamos). En cambio en la universidad eran exámenes tipo test donde mi profesor paranoico alteraba los signos de trozos de código. En mi vida laboral aun sigo esperando que el compilador se vuelva troll y me cambie los signos, pero el formarme para conseguir aprobar los exámenes gigantescos de la FP me ha servido para cubrir sin problemas cualquier parte del proyecto en cualquier fase de su desarrollo.
#74 En mi caso (2003 a 2006) en todas las asignaturas de la carrera orientadas a la programación (bases de datos, sistemas operativos, redes, análisis y diseño de software, algoritmia, estructura de los ordenadores...) se realizaban prácticas con ordenadores y en algunas otras también (por ejemplo en análisis matemático había que realizar programas en "Mathematica" y en electrónica había que simular circuitos con un programa del que ahora no recuerdo el nombre), tanto en la propia Escuela como en casa (principalmente en casa porque en clase no había horas suficientes, pero siempre había clases prácticas al menos para iniciarse un poco en el programa, IDE, etc., a utilizar y/o para resolver dudas) y los únicos exámenes tipo test que he realizado ha sido en algunas asignaturas de matemáticas (por ejemplo en Álgebra Lineal, aunque tenías que realizar el ejercicio en papel para poder saber la respuesta tan sólo entregabas la respuesta en la hoja de test y no era nada fácil aprobar, de hecho era una de las asignaturas con más suspensos de la carrera ya que, a diferencia de los exámenes en los que desarrollas la respuesta en los que la solución puede estar bien, mal o parcialmente bien en un tipo test la respuesta está bien o mal).
Normalmente los exámenes eran muy distintos de los ejercicios resueltos en clase (con lo que no te servía de nada usarlos como chuleta).
Además algunas asignaturas tenían exámenes prácticos delante del ordenador y otras exámenes de programación pero en papel y, en ambos casos, también podían llegar a durar 4-5 horas.
Así que yo diría que las cosas, al menos en mi universidad y en estos tiempos, son muy diferentes a las que tú has vivido.
#74 Supongo que como dije variará mucho entre provincias, hoy precisamente tuve la oportunidad de hablar con alguien, y lo que dije, en lo que es programación la teoría fue más bien poca. También hubo una chica que me comentó en su momento que sus exámenes del primer año fueron en papel. Muy divertido crear un fichero en C con registros y crear funciones para añadir, leer, operar con registros en modo de compilación "hoja".
De todas formas, tampoco nos digamos tonterías, por mucha teoría que te den, tampoco te darán la misma que a alguien que hace una ingeniería en 4 años con toda la presión que hay, y que encima también haya más tiempo para tener mucha más práctica.
Y bueno, precisamente por eso digo que tiene una orientación mucho más práctica, lamentablemente en una universidad se dan muchos contenidos en poco tiempo, y encima con másificación de aulas.
#66 Yo repito que no tiene sentido hablar sobre casos excepcionales, habrá gente de FP y licenciados que simplemente no saben programar aunque hayan sacado matrícula de honor. También hay muchos casos particulares sobre profesores que son mejores que otros.
A mi me parece claro que hay una ingeniería que te da una bases teóricas mucho más fuertes, y luego una FP que te da una bases prácticas más fuertes. Por lo demás, aprovechar todas las posibilidades que eso te habré depende del alumno.
No entiendo porque parece que por decir esto, puede que haya gente que se lo tome como desprecio. Siguiendo lo que dices, sí, se puede sacar toda la teoría de internet, pero es que la práctica también te la puedes buscar por tu cuenta. Según eso nuestro estudio no valdría "nada" y no creo eso. Son dos enfoques muy diferentes, con sus pros y sus contras.
Eso sin quitar que a efectos prácticos, si estoy convencido totalmente que para muchas cosas es mucho mejor contratar a alguien que ha hecho una FP, simplemente porque no necesitas más, y eso es en cierta forma lo que también se crítica en el artículo.
Desgraciadamente, tal y como indica GalliR, los profesionales de la informática acabamos siendo desplazados, a veces incluso en contra de nuestra voluntad, a puestos "de mayor responsabilidad"... y hablo por experiencia propia. Nunca he sido tan feliz como cuándo era un picacódigo; ahora el 90% de mi tiempo es pelea con distribuídores/clientes en preventa y el 10% (siendo optimista) temas técnicos (a veces si "cazo" una consulta ni la derivo al soporte o a programación, la atiendo yo sólo por darme ese gusto y sentirme todavía un técnico).
Y todavía no he llegado a los 40. Mi sueldo ha mejorado, tengo despacho, tengo ventana, tengo vistas... Pero no siento ese hormigueo
En los paises sin apenas cultura tecnológica, lease Españistan, se piensa que ser administrador de proyecto es el paso lógico tras años de programación, craso error, son dos disciplinas muy diferentes y aunque en algunos casos pudiera ser así, normalmente ha de evitarse.
Una buena metáfora es el futbol, solo unos pocos jugadores acaban siendo entrenadores, y pocos entrenadores son exjugadores. Y por supuesto la diferencia entre un buen resultado y uno malo depende más de los jugadores que del entrenador.
Pensar en los programadores como unos picateclas robóticos que se limitan únicamente a implementar una especificación (normalmente incompleta) es absurdo. Cada simple if y decisión que toma el programador sobre el flujo de la lógica puede marcar la diferencia entre el éxito, o un proyecto dificil de mantener o incluso fallido, con los costes que eso conlleva; en mucha mayor medida que las decisiones del administrador sobre las asignaciones de trabajo.
De hecho como decía antes, en los paises con cierta cultura sobre software no es raro ver programadores de "a pie" con 40 años y cobrando sumas mucho más elevadas que los gestores.
#27 Doy fe, estoy ahora trabajando en UK, y en el equipo en que estoy el programador senior (que tiene un poco menos de 40 años) cobra mas que el jefe de proyecto que lo dirige, y no lo ven nada raro.
#40 Yo he visto Windows server 2k y 2k3 con un uptime de año y pico largo. Y un solaris también.
Si bien no eran críticos, tampoco es plan, hay que mantenerlos relativamente actualizados, y hay actualizaciones mayores que requieren reiniciar.
Pero vamos, eran estables y funcionales sin necesitar reiniciar.
No he tocado nunca OS/2,así que no sé si tenía actualizaciones que requerían reiniciar.
Saludos.
Una crítica casi igual se podría aplicar a las consultoras.
No hay incentivos para hacer nada que no se pueda facturar, por lo que es imposible que el producto mejore por propia iniciativa de la consultora.
P.D. En mi empresa hace poco dieron "premios" a los que más tiempo llevaban. Entre ellos un programador senior que llevaba 30 años, y yo creía que la empresa tenía menos tiempo. Aunque claro, aquí la diferencia salarial entre senior developer y engineer no es demasiado alta, por lo que si te gusta la programación no tienes por qué "ascender". Y sí, todos con los que tengo contacto y de los que puedo saber qué estudiaron son titulados, no sé si será política de empresa o simple casualidad.
Perdón por el offtopic.
#49 Y eso sin hablar de que hablar de .Net no pinta nada a la hora de comparar kernels. Que es el punto más flojo de Microsoft ahora mismo. Hasta están consiguiendo poner al día el navegador, aunque de forma bastante conservadora.
Microsoft tiene dos problemas gordos que las distintas divisiones de la empresa ni se hablan, ni colaboran entre sí y duplican trabajo; y que la división de sistema operativos es para darle de comer aparte comida por la burocracia, pequeños imperios que no colaboran entre sí, demasiado conservadurismo hasta para IBM... No sé si para la nueva XBox cambiará, pero la última tenía como sistema operativo un fork del Windowss NT de Windows 2000 mantenido por empleados de la división de entretenimiento. Así que la empresa tiene varios equipos manteniendo kernels incompatibles. Mientras en Linux ahora mismo docenas de empresas son capaces de colaborar en su desarrollo y mantener un rama principal común. Y hasta Google ha conseguido llegar a acuerdos para la mayor parte de los cambios hechos para Android. A veces teniendo que reemplazarlos con cosas hechas por Samsung u otras compañias.
Y Skype aunque lo han comprado va por libre como una división aparte y no han cambiado nada desde que los compro Microsoft.
#49, #53, perdón es WFP (Windows Filtering Platform)[1]. WPF sé perfectamente lo que es porque es una de las cosas que hago ahora.
#57 no sé a que te refieres con "como está organizada la estructura de desarrollo de Linux", y porqué supones que no sé de ello. De linux sólo he dicho que no hay un depurador a nivel de kernel (excepto ñapas tipo UML o cosas raras con el gdb), y que mantener un módulo entre diferentes versiones en un caos. No sé en que me podría ayudar la estructura de desarrollo de linux, si yo sólo he programado módulos.
[1]http://msdn.microsoft.com/en-us/library/windows/hardware/gg463267.aspx
#7 ¿Como que no?
Que algun entendido del tema me diga si herramientas como: dprobes, systemtap/kprobes, lttng, kdb, kgdb, dtrace para linux, lcrash/lkcd, strace, ..., no son utiles para depuracion a nivel de kernel/modulos y estudio de crash dumps.
No conozco el tema, pero si he usado strace/ltrace/xtrace y gdb.
Pos como sería en IBM entonces, que hasta los de Microsoft vieron su sistema de trabajo horroroso (en la época en la que trabajaban conjuntamente en OS/2). Se quejaban de que los programadores de IBM cobraban por líneas de código escritas, lo que llevaba a añadir código basura al sistema que no aportaba nada y solo ralentizaba... NT viene de ahí, de cuando Microsoft vio inviable trabajar en ese plan y se llevó su parte, que recicló como el kernel de NT.
#7 NT es híbrido, no microkernel y lo ejecuta casi todo en modo kernel: https://en.wikipedia.org/wiki/Hybrid_kernel
La ventaja de como esta planteado Windows es que hace más fácil hacer API estable de drivers.
#10 IBM actualmente tiene en plantilla a desarrollladores de Linux.
#11, espero que esa práctica cambiara... e imagino que ha sido así, porque sino habríamos visto cientos de posts quejándose de las aportaciones de IBM al kernel. Pero a mediados de los 90 era mortal.
He tenido el placer de programar drivers tanto para linux como para windows, sobre todo drivers de red. Y bueno, creo que hay diferencias sustanciales entre uno y otro que puede que compararlos en igualdad de condiciones no sea correcto.
No sé cuál de los dos funciona más rápido, pero Microsoft tiene un handicap muy grande: Tiene que integrarse con miles de 3rd partys que no tienen acceso a su código, por lo que tienen que "heredar" todo el legacy (sino sólo hay que ver cuánto les está costando erradicar una mierda de API como TDI).
Otra cosa es, que algunas nuevas APIs de red, como WPF sean una castaña, y que al lado de NDIS palidezcan, es decir, en el kernel de Windows te puedes encontrar oro molido y verdaderas lacras, esto puede ser fruto de la pérdida de talento que comentan en el artículo.
También es verdad, que programar drivers en Windows es bastante más difícil que en linux (al menos hasta donde yo lo he visto), la gestión de IRP's al principio es complicada, y no saber cómo funcionan "realmente" las cosas no ayuda.
Ahora bien, Linux ni de lejos tiene unas APIs tan serias como las de Windows (como comenta #11), y éstas cambian tanto de versión en versión que la programación también se hace complicada, a veces es tan complicado dar servicio a varias versiones del kernel que escribir el propio módulo en sí.
Linux no tiene nada ni remotamente parecido a WinDbg, ni análisis de dumps, ni un sistema de calidad como WHQL para la integración de drivers de terceros, por lo que muchas veces se hacen las cosas un poco a ciegas o confiando en que todo "vaya bien".
Pero bueno, ya he soltado la chapa.
Por cierto, eso que habla de proyect managers, en mi opinión es un subproducto de aplicar Scrum (Microsoft trabaja con esta metodología), donde los proyect managers pueden ser pequeños "tiranos" que lo primero necesitan justificarse a sí mismos, y que todo lo que venga de fuera de su equipo se puede considerar una "intromisión".
#26 Otra cosa es, que algunas nuevas APIs de red, como WPF sean una castaña
WPF (Windows Presentation Foundation) es para la capa de presentación, no tiene nada que ver con redes.
Imagino que te referirías a WCF, pero lo de que es una castaña lo dices tú, ya que teniendo en cuenta para lo que es, yo ni en linux ni en java he visto nada que ni siquiera se le acerque (ni a WCF ni a WPF)
Lastima que aquí se premie cualquier opinión que putee a Microsoft, aunque solo se digan estupideces.
#26 Tendras mucha experiencia como programador de controladores.
Pero ni idea de como esta organizada la estructura de desarrollo de Linux, y sus peculiaridades.
#26 No tienes ni puta idea de la estructura interna del kernel de Linux
¿De donde sacaste que no hay herramientas para debuggear y analizar dumps?
#10 Un respeto a OS/2. En uno de mis trabajos tenían un servidor con este sistema y llevaban más de tres años sin un sólo reinicio. Pídele eso a un Windows...
El que era un sistema bueno de verdad era el NT 3.5 y 4.0. Esa pedazo de capa de abstracción de hardware que tenía. Si hubiera tenido soporte USB todavía seguiría funcionando en muchos equipos.
#18 Yo con NT 3.5 no trabaje pero el 4 es verdad que no se paraba nunca. Eso si, como te saliera un pantallazo podias darte por jodido ya que seguro que era algo grave.
ps: para seguir funcionando hoy en dia mas que soporte USB lo que le faltaria es mejorar su sistema de directorio, el wins era una puta mierda.
Dejando a un lado como se organizan para programarlo, ¿el kernel de Linux, al ser monolitico, no estaba en desventaja frente al de Windows (microkernel)? ¿Un kernel monolitico no iba volviéndose más lento a medida que añadían funciones?
Linux es cada vez peor, según su creador
Linux es cada vez peor, según su creador
ecodiario.eleconomista.es#7 El hecho de ser monolítico no tiene nada que ver con que vaya lento, todo lo contrario. En todo caso, Linus sigue pensando que el rollo de los microkernels es una paja mental producto de las drogas. Cito una frase suya de 2012:
We're not masturbating around with some research project. We never were. Even when Linux was young, the whole and only point was to make a usable system. It's why it's not some crazy drug-induced microkernel or other random crazy thing.
No me convence
El articulo es muy interesante, es extrapolable a otras ambitos empresariales. Que dificil es que "el engranaje" funcione bien, es decir que haya comunicación, que la gente sea conocedora y participe del plan global y así no caigamos en la trampa de tratar de conseguir los objetivos a todo costa, incluso a costa de los propios interes de nuestro negocio.
Otra reflexión Linux es una plataforma abierta, carente de propiedad, mas barata y además mas eficiente! es para tomar nota y quitarnos de la cabeza viejos axiomas a todas luces falsos.
Menos mal que no solo de kernels viven los sistemas operativos...
A mi siempre me haparecido ironico, que al programador mas experimentado y con ams años, lo asciendan y lo hagan director de proyecto. Es decir, al que sabe programar, lo quizas de programar y lo pones a hacer otra cosa (que seguramente no sepa ni se ha formado apra eso). Y con toda probalidad pongas en el puesto vacante a un nuevo trabajador sin experiencia
Es como si en el una obra, pones a un albañil a hacer tabiques, si no le salen demasiado rectos, siempre se puede repellar y/o echar gotelé para disimularlo.
Cuando lleva un tiempo haciendolos perfectos y rectos, llega el jefe de obra, le da una palmadita y le dice que como ya lleva tiempo y confia en el, lo pone en un puesto de mayor responsabilidad, poniendo azulejos, que es mas delicado porque hay que ponerlos parejos y bien para que queden bonicos. No hay duda que algunas destrezas aprendidas le ayudaran a poner azulejos, pero al que pongas a tabicar no va a ser tan bueno.
Fos, Gallir
El artículo contiene un buen puñado de faltas ortográficas y gramaticales.
Seguramente ha sido escrito desde windows.
Para mí esta claro porqué, es muy sencillo, se llama monopolio. Cualquier PC que te compres lleva windows pre-instalado. Luego, no tienes que esforzarte mucho para venderlo, lo vas a vender igual. Cambian la parte visual, lo queve la gente, a nadie le importa lo técnico salvo a nosotros los informáticos. Si, puedes formatear e instalar linux u otra cosa, pero la pasta ya se la ha llevado MS.
Por eso es buena la competencia, cuando la hay, tienes que crear un producto de calidad para competir. Mirad como ha mejorado el Internet Explorer desde que tiene competencia.
#5 Vamos, que eso de programar es de pobres, no?
Un ingeniero, como su propio nombre indica, ingenia, no dirige.
Dirigir lo hace alguien que tiene mucha experiencia ingeniando y tiene el culo pelao de bregar con todo lo que rodea al ingeniar.
#4 ei, que yo no he dicho nada!
#4 Un ingeniero es aquel que resuelve problemas y optimiza los recursos existentes. Da igual desde qué escalafón del proyecto lo haga, si desde la dirección o desde la obra (en este caso, programación). Lo importante es que las cosas funcionen gastando el mínimo de recursos posibles.