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.

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.

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.

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.

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.

antonio :
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.

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.

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”.

“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.

http://is.ls.fi.upm.es/docencia/proyecto/docs/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.