Etiquetas
En el artículo «I Contribute to the Windows Kernel. We Are Slower Than Other Operating Systems. Here Is Why.» se transcribe el comentario (luego eliminado) de un anónimo que se identificó y aportó pruebas como programador de Microsoft. En el comentario explica su opinión de por qué el núcleo Windows NT (el que se usa en todos los siguientes, 2000,XP, Vista, 7 y 8). Más allá de las anécdotas, y de que es una visión parcial y subjetiva, es muy interesante lo que desvela. En pocas palabras, la carencia de calidad y eficiencia son más un problema social más que técnico:
- Falta de incentivos, o incentivos equivocados.
- Dar mayor importancia a cumplir los planes establecidos sin desviaciones que aceptar cambios no planificados para mejorar la calidad del producto.
- La carencia de programadores con experiencia, o el exceso de programadores recién graduados.
Es muy interesante la lectura, desvela los problemas de gestionar y programar sistemas complejos. Cualquier economista explicaría que hay que establecer los incentivos adecuados, sobre todo en entornos como la programación donde se trata de desarrollar sistemas tan complejos que tienen más componentes que el avión más grande del mundo y tantas formas de interacción -muchas órdenes de magnitud superior a cualquier sistema de componentes físicos- que escapan a nuestra capacidad de comprensión.
Ese incapacidad cognitiva de siquiera conocer la magnitud de la complejidad hace que sea imposible hacer un diseño inicial que tenga en cuenta todas las interacciones y casos. Por ello es imposible asegurar que no haya bugs y, por supuesto, que el sistema desarrollado sea eficiente. Eso requiere, tal como ya lo contaba Brooks en los ’70, el «mantenimiento» de los programas, que consiste en la mayor parte del ciclo de vida del software. Ese mantenimiento no consiste sólo en arreglar problemas, también en mejorar el código (para controlar mejor la creciente complejidad) y la eficiencia.
En el núcleo Linux es un buen ejemplo en ese sentido: se usaron las ideas y principios de modularidad de Unix, es software libre con todo a la vista del público (el código, y las discusiones técnicas), la gestión de Linus Torvalds (y los responsables de módulos) han creado una comunidad muy meritocrática (talk is cheap, show me the code) donde el respeto a los clientes (desarrolladores de programas a nivel usuario) es prioritaria, revisión de pares, se debate con dureza cada propuesta y cambio, se critica duro al que presenta propuestas malas, pero también se reconoce y halaga al que consigue mejorar funcionalidades ya establecidas y maduras.
Esa es una de las principales diferencias que se extraen del artículo.
En Microsoft [presuntamente] no funciona así, los responsables de módulos tienen más razones para rechazar mejoras que para introducirlas, los Project Managers no ven con buenos ojos que haya desvíos del plan de trabajo, los grupos de testing no quieren saber nada de volver a probar y adaptar unidades de verificación. Es decir, no hay incentivos para mejorar las funcionalidades existentes y que no sean prioritarias en la empresa. En consecuencia, la eficiencia de sistemas con modelos de desarrollo más similares a Linux acaban siendo superior, sobre todo en las áreas y funcionalidades ya maduras.
Otro de los problemas que se menciona es el abandono de los programadores senior y la contratación de nuevos que acaban de salir de la universidad. Estos no son capaces de valorar la complejidad del sistema, ni de conocer por qué fueron tomadas las decisiones técnicas anteriores.
Este último punto es interesante, sobre todo en un gremio -y en un país- donde se valora poco la experiencia de los programadores. Salvo las empresas punteras en desarrollo de software equiparan los [excelentes] salarios de los programadores con la de los gestores (no es nada raro que un programador senior de Google cobre 150.000€). Ocurre en muchos países, pero sobre todo en España, tener 40 años y seguir programando parece más un fracaso profesional que el éxito de un programador apasionado.
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.
Además de lo mejorable que es nuestra educación, y como últimamente me está apasionando el tema de gestión de desarrollo de software, del comentario me han quedado algunas cosas más claras:
- Los planes y metodologías son herramientas, no un fin en sí mismo, como terminan de creerse sus responsables y evangelistas.
- Se deben crear incentivos, no sólo monetarios, para motivar a que los programadores desarrollen mejoras para cualquier parte del sistema. Esto implica, entre otras cosas, descontar un porcentaje de los recursos disponibles para implementar nuevas funcionalidades y reservarlos para mejora de la «calidad global».
- Valorar debidamente a los programadores experimentados, que empieza por reconocer -sobre todo entre nosotros mismos- las carencias inevitables de un recién graduado, y la rápida evolución de la ciencia y tecnologías informáticas.
- Debemos empezar a esforzarnos en formar a profesionales cuyo objetivo sean jubilarse como programadores, no sólo un camino intermedio para lograr mejores salarios en otros puestos de gestión o dirección.
- Sobre todo, reconocer que tenemos problemas cognitivos para visualizar mental y adecuadamente la enorme complejidad de los grandes sistemas informáticos.
Ricardo Galli, de software 
Pingback: Por qué el núcleo Windows NT es peor que Linux: problemas sociales y de incentivos
«En el comentario explica su opinión de por qué el núcleo Windows NT (el que se usa en todos los siguientes, 2000,XP, Vista, 7 y 8). »
Creo que en esta frase faltó terminar la idea. Y es una linda parábola sobre el artículo 🙂
A ver Ricardo, una pregunta, ¿te has basado realmente en la empresa Microsoft para hacer algunos de los comentarios o vienes a escondida a la que yo «sufro» para ello?
Creo que hay detalles que son muy de, lo que les gusta llamar, «gran empresa». 😛
tEstoy de acuerdo con el artículo y sobre todo en la frase que dice: «…tener 40 años y seguir programando parece más un fracaso profesional que el éxito de un programador apasionado.»
«Un ingeniero informático no programa, dirige proyectos» es que para eso se forman a los ingenieros, los que programan suelen ser FPs, por lo menos en España. Lo que pasa es que el puesto que debe de ocupar el FP, lo esta ocupando un Ingeniero, entendiendo el programar como picar código.
#4 ¿De verdad crees que un ingeniero no debería programar? ¿Qué solo debería hacerlo un FP? Ese tipo de pensamiento es el que hace que una empresa de Sillicon Valley y una tecnológica española no se parezcan en nada.
El rendimiento del kernel de Linux puede ser muy bueno, pero luego están los drivers de las tarjetas gráficas y lo joden todo.
#5 No, digo que si hay unos cursos y una formación para programadores, y que los puestos de programadores tienen la categoría de FP, que un ingeniero programe es por su cuenta y riesgo.
Yo siempre digo lo mismo, un Arquitecto si se pone a hacer paredes, sabe lo que va a cobrar y cuales son sus responsabilidades. Y un ingeniero de caminos si se pone a encofrar ya sabe lo que hay y en informática parece ser que un ingeniero tiene que ser el albañil, si se forma a alguien para ser ANALISTA estar de programador es como formar arquitectos para tenerlos de albañiles.
Ricardo, tu artículo es interesante. Pero, un programador, nunca podrá jubilarse como tal, al menos siendo un programador «brillante y rápido», podrá tener mucha experiencia y saber cada vez más arquitectura y con suerte patrones de diseño. Pero su «fastcoding», el alma de los grandes programadores que para mí es como el mojo, o la inspiración, se pierde con la edad. Simplemente por que nuestros cerebros envejecen. Al menos «en media», un programador medio, de 25-30 años, supera con creces en actualidad de conocimientos y en velocidad de programación a uno de pongamos 45-50, ya no digamos uno de 60. La explicación a la degradación de nuestro cerebro con la edad, sí el tuyo y el mío también, puedes verificarla en todos sus aspectos en la wikipedia: http://en.wikipedia.org/wiki/Aging_brain
Con esto no digo que Linus no esté contribuyendo como el que más, o que no haya super programadores con 60 años. Pero si ese a los 60 es super, habría que verle codificando con 30 años. No hay color.
#7 con todo respeto, realmente creo que estas totalmente equivocado, no entiendes la profundidad de lo que quiere decir programar bien, para lo cual se necesitan habilidades superiores y años de formación, te puedo asegurar que gestionar proyectos y ser un ANALISTA es por mucho, mas sencillo, que hacer un buen sistema informático.
#7 El problema es que la formación de un ingeniero informático no debería ser únicamente la de analista o jefe de proyecto. En algunos casos, la labor de programación puede realizarla un FP. Pero en otras situaciones, programar es una actividad de un alto nivel intelectual que requiere la máxima formación posible.
Sería imposible desarrollar Linux por gente de FP por mucho que haya ingenieros detrás analizando o dirigiendo «sabiamente». El buen software requiere que el propio analista se «ensucie» las manos.
La comparación de la informática con el mundo de la construcción es muy recurrente: un arquitecto/ingeniero diseña casas/puentes y los albañiles las construyen. Yo creo, sinceramente, que no es extrapolable a nuestro dominio; es más, creo que es profundamente errónea. El diseñar un sistema informático y su implementarlo deben ir ligados y deben hacerlo las mismas personas. De hecho, así es como trabajan en las empresas de Sillicon Valley y creo que no les va nada mal. En cambio, en España primamos una jerarquía completamente vertical y separada cuyos pésimos resultados todos conocemos.
Programar no es sencillo, no más que analizar y diseñar. Cuando los ingenieros dejemos nuestros aires de superioridad y programemos, obtendremos algo de calidad. Mientras tanto, pues seguiremos así.
elhumero, eso que defiendes es una tontería como una casa, que se descubre en cuento trabajas un poco de verdad en proyectos de software reales.
«elhumero» es un nick muy apropiado para este usuario. Hay algo más «vende humos» que un ingeniero informático que ni programa ni valora la programación?
Cuánto daño han hecho los ingenieros de power point a este país y al mundo en general.
#7 te equivocas de cuajo: es imposible poder gestionar o, simplemente, analizar, si no sabes programar *bien*. No voy a hacer analogías con arquitectos porque no conozco su trabajo, pero si no sabes cuál es la dificultad de implementar una historia de usuario porque no lo has hecho nunca, ¿qué base tienes para sacar la cartita, o para distribuir los pesos, para adjudicar tareas, para reservar esfuerzo y plazo? Lo mismo si nos vamos a formas de trabajar más tradicionales, en las que hay que pasar por una fase completa de diseño. Ninguna, cero. Si no sabes programar, no vales para analizar ni para gestionar.
#9 también te equivocas: te sitúas en el extremo opuesto a #7 por mero afán de contestar por contestar. Un análisis bien hecho es un arte igual que un código bien escrito. Y gestionar bien tiene mucho arte. Y puede facilitar o poner muy difíciles las cosas al resto del equipo.
Y para cerrar el círculo virtuoso que todos deberíamos llegar a entender, más vale que si te pones a gestionar saques tiempo para reciclarte y programar de vez en cuando, porque si no, el principio de Dilbert va a estar pendiendo sobre tu cabeza como una espada de Damocles.
Pues a mi me da igual que la mayoría quiera fracasar intentando ser jefe de proyecto y sí, me gustaría jubilarme siendo programador, eso sí, sin la puñetera manía de tener que parir proyectos durante un año. Más planificación y tiempo de pruebas y menos prisas por sacar el software lleno de fallos, para luego tener que pasar verguenza.
#12 El humero no viene de nada de humo. Viene de una palabra de mi tierra y no significa humo. El insultar sin argumentar hace que tenga mucho sentido la frase de Groucho Marx (creo) de «Es mejor estar callado y parecer tonto, que hablar y despejar las dudas definitivamente».
#11 Llevo casi 20 años en esto de la informática, y he programado de casi todo y en casi todos los tamaños de empresa, desde la mía propia, a multinacional pasando por PYMEs y cárnicas, llegando a la bonita conclusión que la diferencia, la mayoría de las veces entre una PYME y una multinacional, esta en que en la PYME hablas en persona al presidente y en la multinacional te escribe emails contándote lo guays que son.
Los últimos 7 años me he dedicado a la consultoría y a la administración, que me gusta mas que la programación.
Nunca me he dedicado a vender nada y no sé usar el powerpoint, y casi no sé usar Windows XP, Vista o 7, me he pasado los últimos 7 años con una pantalla negra llena de letras, bueno con el putty y otros terminales.
Es mas, yo no soy ingeniero, soy Diplomado en informática de sistemas, que no ingeniero técnico, ni ingeniero, ni nada parecido. Y entre en la diplomatura por mi titulo de Técnico especialista en administración de empresas y comercio, especialidad de Informática de gestión o FPII de informática.
He programado, he analizado, he administrado e incluso he tenido que hacer las tres cosas al tiempo, y si sé que que un buen análisis te quita de encima mas del 50% del tiempo a invertir en la programación. Y que perder tiempo haciendo un buen análisis hace que el proyecto gane mucho mas tiempo y se haga todo mas relajadamente y que por el contrario un mal análisis te lleva a te puede hacer tener que repetir todo cuando estas a punto de terminar.
#13, estoy de acuerdo contigo en casi todo, pero lo que digo es que un ingeniero informático si esta en un puesto para el que la categoría es inferior a la suya, no puede quejarse de que le pagan mas o menos y el puesto de programador es una categoría inferior a la de un analista.
#10 y #9 el símil de la construcción es extrapolable a nuestro campo, un buen análisis, bien hecho no deja lugar a la imaginación o a desarrollar la inteligencia del programador, simplemente el programador pone ladrillos, porque en teoría te dan el lenguaje y un pseudocódigo a desarrollar, las pantallas, las relaciones, la entrada y la salida
El debate parece que se dirige hacia la cuestión de si la ingeniería informática debe enfocarse en la ingeniería del software/gestión o en la programación. Algunos de los debates colaterales creo que son superfluos, como el de que si un programador de 60 años programa mejor o peor que uno de 30, lo más suave que se me ocurre al respecto es que este debate se plantea aquí … en España, porque en EEUU por ejemplo u otros países con las cosas más claras en estos temas no tendría sentido, pero hay uno que creo que si es muy interesante, el de si para ser un buen gestor es necesario ser un buen programador, que reformularía con la siguiente afirmación, para ser un buen programador es necesario tener conocimientos de ingeniería del software y de gestión de proyectos. Para justificar esta afirmación voy a echar mano de la experiencia. He sido gestor de proyectos durante varios años, ahora soy autónomo y programo y gestiono y vendo y … me lo guiso y me lo como. En los años en los que estuve exclusivamente gestionando pasé por muchas situaciones que demuestran la verdad de la afirmación, pero una sobre todas. Me incorporé a una empresa en la que, en el primer proyecto del que me hice cargo, contaba con uno de los mejores «programadores» que he conocido, además cumplía con el perfil de analista en el sentido de que recogía perfectamente los requerimientos del cliente y desarrollaba aplicaciones a la primera que apenas había que modificar, que dejaban muy satisfecho al cliente. Resulta que justo antes de terminar el proyecto el programador cambió de empresa por lo que el módulo que estaba desarrollando en solitario hubo que pasarlo a otro programador, fue tarea imposible porque el código no solo carecía de cualquier comentario, si no que carecía de estructura por lo que el traspaso se complico exponencialmente, por lo que retrasó la entrega del aplicativo … aprendí mucho de aquella experiencia.
Totalmente de acuerdo contigo, soy analista de sistemas, con estudios en ingeniería de software sin concluir, sin embargo trabajo como programador porque me gusta y a diferencia de lo que creen dirigir es infinitamente mas fácil que programar (y que conste que he llevado proyectos como analista), programar es un arte aunque muchos no lo vean así por su incapacidad, a mi me seria muy fácil patearles el puesto pero luego ya no hago lo que me gusta y apasiona.
Pingback: Por qué el núcleo Windows NT es peor que Linux: problemas sociales y de incentivos | BRiveira
Hay un párrafo del artículo que me gustaría comentar … a ver si puedo aportar alguna idea.
«Ese incapacidad cognitiva de siquiera conocer la magnitud de la complejidad hace que sea imposible hacer un diseño inicial que tenga en cuenta todas las interacciones y casos. Por ello es imposible asegurar que no haya bugs y, por supuesto, que el sistema desarrollado sea eficiente. Eso requiere, tal como ya lo contaba Brooks en los ’70, el “mantenimiento” de los programas, que consiste en la mayor parte del ciclo de vida del software. Ese mantenimiento no consiste sólo en arreglar problemas, también en mejorar el código (para controlar mejor la creciente complejidad) y la eficiencia.»
La complejidad no aparece solo en grandes proyectos, aparece en cualquier proyecto que tenga incertidumbre, cualquier proyecto que afronte problemas de los que no se conozca la solución, que suelen ser la mayoría de los que aborda la ingeniería del software. Es decir que lo común son proyectos en los que «es imposible hacer un diseño inicial que tenga en cuenta todas las interacciones y casos», si esto no se ve así es porque se está en contra de la realidad a partir de unos planteamientos filosóficos equivocados, como se indica muy claramente en este texto.
Haz clic para acceder a FilosofiaIS.pdf
En relación con esto y volviendo a mi comentario anterior, un buen programador debe conocer perfectamente las distintas metodologías que existen, es lamentable que haya programadores (que los hay y muchos) que no entiendan la relación entre los paradigmas de programación y las metodologías de desarrollo, que por ejemplo no entienden que la programación orientada a objetos tiene sentido porque facilita la gestión de la incertidumbre y se manifiesta en desarrollos iterativos e incrementales. Un programador también debe conocer la gestión de proyectos, no solo porque pueda evolucionar como gestor si no porque siempre va a estar involucrado en proyectos y que, por lo tanto, la calidad de su trabajo no solo se mide por parámetros técnicos si no por parámetros de costes globales del proyecto.
Pingback: Por qué el núcleo Windows NT es peor que Linux: problemas sociales y de incentivos | AleQwerty Blog GNU/Linux
Una cosa es ser analista, para lo que no hace falta ser Informático, y otra cosa programar. Programar consiste en plasmar algo que se ha ingeniado, y si lo hace el mismo el programa será fiel a la idea.
#15. El problema de lo que dices es una frase que pones en esta respuesta a #7, ¿por qué la categoría de programador es inferior a la de Analista en este país? Eso no pasa en todos los países ¿Estás de acuerdo con esa situación?
Para mi son dos categorías distintas que, si bien el sueldo base de un programador sí debería ser inferior al base de un analista (y, antes de ser analista, exigir siempre que se haya pasado por la otra categoría), los sueldos superiores en ambas deberían ser en función de la valía de la persona, no unos inferiores a los otros.
Yo sí soy ingeniero y me encanta la programación. He pasado también por todos los puestos. Afortunadamente ahora estoy en un puesto relativamente alto y me dejan programar (será porque saben que les compensa).
Recuerdo una frase de la carrera «programar lo puede cualquiera», a la que yo añadía «sí, pero muy muy pocos pueden hacerlo realmente bien». Casualidad que los que la dijeran eran normalmente los que menos idea tenían de programar.
También he visto cosas como ingenieros que, al salir de la carrera, ya iban directamente a ser analistas, «porque ellos lo valían». No había nada peor que esos análisis, no había por donde cogerlos. Sin una mínima base como programador, no conoces los problemas reales. Las estimaciones de tiempo eran un disparate. Pero claro «son ingenieros».
#8 ¿Influye la edad en la calidad como programador?
http://navegapolis.com/index.php/93-programadores-y-edad
Cuanto daño ha hecho y está haciendo el eXtreme Programing mal entendido. Lo peor que le está pasando al XP son sus defensores talibanes, cosa muy común por otro lado en el mundo de la ingeniería del software. Para no enrollarme para justificar porqué considero que estos defensores pecan de extrema puerilidad pongo este artículo
http://is.ls.fi.upm.es/docencia/proyecto/docs/xp.html
Incluyo el resumen del artículo que es muy aclaratorio
… la ingeniería de software está en ciernes. Su primer marco teórico fue insuficiente y se ha producido una eclosión de empirismo que debe fertilizar el terreno para un segundo marco teórico, ya visible. Del primer marco teórico nos sentó mal su carácter hegemónico. La diversidad es una riqueza que debemos aprovechar. Todos los modelos, XP, la Espiral, Caos, la Cascada, …. todos tienen un lugarcito donde son útiles y parte de la profesionalidad es saber aprovechar la utilidad de cada uno en su momento.
#15: Que has estado en una cárnica se te nota mucho, créeme.
Lo demuestras diciendo que la categoría de un programdor es inferior a la de un analista. Eso lo será en las empresas (posiblemente penosas tipo Indra, Everis, etc) que conocerás. Las líderes del sector de verdad (Atlassian, Valve, Google, Spotify) no siguen ese esquema, y no comparemos resultados.
John Carmack no es ingeniero (ni diplomado), es programador (de los de verdad) y le da mil vueltas a todos esos hinjenieros de software que se llaman ingenieros y la mitad no saben ni pintar una gráfica logaritmica.
Si programar es tan fácil e inferior, por qué en las mejores empresas de mundo las pruebas técnicas son de algoritmia (entre otras, claro)?
¿Y qué es eso de perder el tiempo haciendo un pseudo código? Eso es muy de la «vieja escuela» rancia española. Como lo de decir aplicativo, más o menos xD.
Ay, estos informáticos de banco / empresa rancia que se creen que no existe vida más allá de eso.
¿Que dices qué de ReactOS? http://www.reactos.org/about-reactos
Reblogueó esto en David Pelayo.
Desde mi humilde opinión se pueden señalar varias cosas interesantes:
-los recursos de linux son infinitos por si se os olvida,en cuanto a mano de obra Windows esta en clara desventaja y casi cualquier otro proyecto/producto que el hombre fabrique/diseñe/use.
-las personas son la pieza clave y cada una es un mundo,pero normalmente no es que te hagas mas lento o tonto con la edad, mas bien no se puede tener la misma dedicación con 20 que con 40 años dado que el mundo de la informática es el infinito aprender en el libro de nunca acabar y la gente suele tener mas inquietudes y cosas que hacer en la vida que estar 16 hora delante del ordenador
-las empresas de este mundillo hacen dos tipos de personas:parados idealistas o maquinas de picar carne…elige…
Linux me hace sentir orgulloso de ser humano y ojalá muchas mas cosas se hicieran de la misma manera
Resumen de una parte que se me ha grabado. Todos quieren ser jefes y nadie quiere ser indio. Por lo que deduzco, en las distintas universidades de informática hay poco o ningún interés en llegar a ser un buen programador… todos quieren llegar a ser unos buenos gestores… Así nos va.
Y la frase de «esforzarnos en formar a profesionales cuyo objetivo sean jubilarse como programadores» me recordó a «¿Un mundo feliz?» de Huxley. Los alfas para la gestión y nos gamma a programar.
Y luego me dicen que las universidades no son castas. ¿Como no quieren intrusismo entre los programadores si a los universitarios informáticos no les interesa programar por que les parece de pringaos? Pues ya llega un físico o un matemático o un farmacéutico rebotado a hacerlo por ustedes, tranquilos, ustedes dirijan.
Pero… ¿cuantos puestos de «jefe» hay por cada programador? Ya tienen el motivo por el que están ustedes en paro señores informáticos, y no es por el intrusismo, es por que no todo el mundo puede ser jefe. Los coches tienen 4 o 5 plazas y conduce uno.
“La pogamación es como un toro” que diría Jesulín… es lo de ese novillo que le dice a su padre toro “papa, papa! bajamos corriendo y nos tiramos a una vaquilla?” y ese padre le dice “no hijo, vamos despacio y nos las tiramos a todas”… pues la programación lo mismo, si te dejan o te respetan puedes ir arreglando todos los puntos… sino, pues un parche corriendo y fuera… te puede pillar el crash y darte un revolcón… o te toca lidiar con unos marronacos con unos cuernos que no veas.
Os voy a hacer una pregunta, porque un Ingeniero aeroespacial se dedica a pintar con resina epoxidica una fibras de carbono para un satelite? o a pegar papel de una aleación metalica en una superficie? no lo deberia de hacerlo un FP en la nasa?
Pingback: Sin tiempo para escribir.173 - Carrero
#8 y #21.
Creo que para mantener al mismo nivel la mente según pasan los años hay que «entrenar».
Seguir programando, aprendiendo nuevos lenguajes, y caña caña y más caña programando.
Si se hace esto se puede estar a un muy buen nivel con 45, 50 y espero 60 años. Pero claro, para «entrenar» tan duro te tiene que gustar programar, sea lo que sea lo que diga tu título de mayor grado.
Tengo 46 años, ingeniero y programo microcontroladores. No me cuesta aprender entornos nuevos, lenguajes nuevos y procesadores nuevos. Dedico bastantes horas a aprender cosas nuevas.
Sinceramente, mi capacidad de trabajo es muchisimo superior a la que tenía hace 20 años, no en horas, pues entonces podía programar 16 horas al día, pero si en resultados.
No tengo ninguna intención de dejar la programación.
Bueno el problema es que ahora vas a tener que programar hasta los 67 años que está la edad de jubilación. Me imagino una sala de desarrollo con veinte tíos y tías de sesenta y pico años programando con extreme programming. Ese es el futuro que os espera a todos 😉 y mejor que sea software libre para que sea un trabajo social.
Muy cierto eso de que se cree erroneamente en la Universidad de que el ingeniero es alguien que manda técnicos en la etapa de codificación. El ingeniero debe inmiscuirse muchas veces en todo el ciclo de vida del software
> Llevo casi 20 años en esto de la informática
Hacen falta 10,000 horas de práctica para adquirir maestría en algo, pero solo si realiza con la intención deliberada de mejorar lo que haces.
Lo primero que te preguntan en una entrevista en el extranjero son estructuras de datos, algoritmos, y rendimiento O(n). Obras clásicas sobre el tema son “Algorithms”, el “CLRS”, o “The Art of Computer Programming”. Este último probablemente necesites ser ingeniero para entenderlo.
Sin estos conocimientos es posible crear software mediocre como casi todo el que se hace en España. Pero en el extranjero, en una empresa decente, no cuela. En España desconocemos nuestra propia ignorancia porque la mediocridad nos rodea como el agua a los peces.
> al menos siendo un programador “brillante y rápido”, podrá tener mucha experiencia y saber cada vez más arquitectura y con suerte patrones de diseño
Con suerte, el arquitecto sabrá patrones de diseño. Acabáramos.
> Pero su “fastcoding”, el alma de los grandes programadores que para mí es como el mojo, o la inspiración, se pierde con la edad.
Que poco mundo han visto algunos. Y eso que stackoverflow está a un click de distancia.
Hablando de Linux les comparto 10 cosas que so sabia que funcionan con Linux http://zibertronicos.blogspot.com/2013/04/10-cosas-que-no-sabias-que-funcionaban-con-linux.html