Como estan otro dia mas y otro momento mas, esto es algo que me encotre por ahi en la red y me gusto
Lo encontre en el blog de Antiguo y abandonado blog de Ricardo Galli (http://mnm.uib.es/gallir/posts/2007/08/11/1142/)
Estás convencido que eres “muy buen programador”.
En general los buenos programadores interactúan y trabajan mucho con el código de otros programadores, y siempre hay alguien que tiene soluciones más creativas, eficientes y elegantes que lo que se le puede ocurrir a una sola persona.
Los buenos programadores suelen pensar que hay demasiadas personas que programan mejor que él.
Reconoces inmediatamente a Jobs, Gates o Torvalds pero no sabes quiénes son y/o qué han hecho Turing –además de su modelo matemático tan conocido–, von Neumman –además de su famosa definición de “arquitectura”–, Dijkstra, Knuth, Wirth, Kernighan, Ritchie, Engelbart, Corbató, Hoare, Minsky…
¿Irías a un médico que no sabe qué ha hecho Pasteur o Ramón y Cajal? Pues eso. (No significa que saber la vida de esos personajes garantiza ser buen médico, pero un buen médico seguro que lee mucho sobre su profesión, si no sabe es que ni siquiera se preocupa en leer más allá de lo que le exigieron en la carrera, y que además se le olvidó una gran parte).
A primera vista del código de programas grandes de otras personas dices “vaya mierda de código, muy complicado, yo lo puedo hacer mejor”.
En general los programas grandes son desarrollados por muchas personas, cada una con su visión –a veces contradictoria con otros– y estilo propio. Aunque haya sido desarrollado por una sola persona, seguramente ésta evolucionó y cambió –en general a mejor– durante el desarrollo. También van cambiando la “realidad” y las herramientas, lo que implica que las soluciones no son siempre las mismas. Además el software se hace cada vez más complejo y requiere soluciones sofisticadas para solucionar los diversos problemas –por ejemplo las race conditions– que aparecen.
Un programador que ha participado en proyectos grandes reconoce inmediatamente estos patrones y problemas asociados, además de tener muy claro que una sólo persona es incapaz de desarrollar grandes programas por sí sola, por eso nunca desmerecería el trabajo de otros sin un conocimiento exhaustivo del programa y sus problemas asociados (y lo más seguro es que envíe parches o soluciones mejores).
Justificas que tu código es ilegible para no mostrarlo o publicarlo.
Este es un problema bastante importante en la gente que empieza a programar… y si perdura con el tiempo es que nunca ha llegado a comprender que los lenguajes de alto nivel se han desarrollado para las personas, no para la CPU –que sigue entendiendo sólo binario–.
Así te encuentras con código sin sangrar, variables y funciones con nombres que no dan ninguna pista de lo que hace –kaka, pepito, f1, v1…–, variables de una letra –como i, j, k– usadas en variables que no son contadores ni índices, ningún comentario… o lo que es peor, exceso de comentarios del tipo /* asigno 0 a la variable i */.
Como las novelas, ¿alguien leería novelas sin ningún tipo de estructura de oraciones, párrafos y capítulos? ¿o sin signos de puntuación o escritas en lenguaje de teléfonos móviles? Si uno sabe de antemano que su código será revisado y modificado por otras personas se plantea escribirlo de otra forma, más acorde con el estilo de cada lenguaje y que sea agradable de leer.
Ésta es una gran ventaja de los programadores de software libre, además que se programa pensando en que otros lo mirarán, en general ya ocurre lo que está explicado en #2: se aprende mucho mirando el código de otros.
No sabrías definir en pocas palabras qué es la programación estructurada, ni sus relaciones y ventajas/desventajas con las arquitecturas y diseño del hardware.
Pues eso, un buen programador sabría explicar que las estructuras de control tienen un sólo punto de entrada y puede tener varios puntos de salida –aunque hubo bastantes discusiones sobre este aspecto–, y que estas restricciones tienen mucho que ver con las “localidad espacial y temporal” del código –además de las ventajas obvias del código fuente de alto nivel estructurado–.
Afirmas “el último lenguaje/librerías/framework XYZ es el mejor”. O que “C y ensamblador desaparecerán”, o peor aún, “el C++ reemplazará al C en los sistemas operativos”.
Cualquiera que haya vivido o leído sobre las diferentes tecnologías y soluciones informáticas entenderá muy bien lo que explica Brooks en “no existe la bala de plata” (There is no silver bullet, mejor traducido como “no hay soluciones mágicas”). Cada lenguaje además tiene sus ventajas y desventajas para cada tipo de problema. Hay cosas que se pueden solucionar mejor con un lenguaje que con otros. Por ejemplo el tratamiento y control de la memoria –gracias a los odiados punteros y asignación dinámica de memoria– que se puede hace con C son casi imposibles o tan costosos que no merece la pena en lenguajes como Java. Aún más, hay cosas necesarias en determinados programas que sólo se pueden hacer con ensamblador, como gestionar registros, TLB, cache, etc.
El que crea que con su lenguaje preferido puede solucionar todo es como el refrán para el que sólo tiene un martillo todo lo que ve son clavos. La informática y programación es mucho más amplio que programar sistemas de facturación o páginas web.
Te dicen que puedes tener una race condition en tu código y pones cara de pasmado.
La programación de sistemas modernos es cada vez más compleja, lo que hace que habitualmente se usen modelos de multiprogramación, programación concurrente y programación distribuida. Incluso la programación web es un ejemplo típico de multiprogramación. Todos esos modelos tienen asociados los problemas de concurrencia por compartición de recursos que hacen que los programas tengan fallos que parecen casi aleatorios aunque los algoritmos analizados independientemente sean correctos. Los conceptos y problemas de concurrencia son de los más difíciles de aprender, lo que sólo se logra con el estudio de los problemas fundamentales y mucha práctica.
Piensas que en la universidad deberían enseñar Java desde el primer curso y que enseñar Pascal no tiene sentido.
Este es el típico argumento de los que piensan que la universidad sólo debe enseñar lo que “demanda el mercado”, o aún peor, que él o ella sólo debe aprender lo que demanda su mercado.
El primer objetivo cuando se empieza a programar es aprender qué es un algoritmo, cómo se representa en un lenguaje de alto nivel, estructurado, secuencial e imperativo –es el modelo más usado y con más métodos formales de diseño y verificación–. Lenguajes como C++ o Java son antes que nada estructurados, secuenciales e imperativos.
Estos son conocimientos previos necesarios para aprender correctamente las abstracciones y estructuras orientadas a objetos, empezar con estos lenguajes con abstracciones y construcciones más complejas sólo introducen problemas y ruido en el aprendizaje, y lo que es peor, introduce vicios que luego son muy difíciles de eliminar.
Te han explicado alguna que tu código quizás se ejecute más rápido si lo compilas para reducir el tamaño antes que optimizar código y has pensado que te engañaban.
Así como está enunciado parece una tontería, pero sólo podrían entenderlo los que tienen un conocimiento más profundo de los que conocen a la arquitectura del hardware que ejecutan al programa. Esto significa conocimientos de gestión de memoria virtual, memoria cache, características del TLB, etc. (De hecho este es un caso real, el núcleo del Linux, la velocidad de los procesadores se incrementó notablemente más rápido que la memoria RAM, por lo que el papel de las técnicas de caché creció en relevancia).
Eres parte del movimiento mileurista, o te quejas del intrusismo laboral.
No conozco a ningún buen programador que cobre mil euros al mes –y conozco a muchísimos, la ventaja de haber sido su profesor–. El paro de los programadores es casi cero –casi diría que negativo en Balears, es una lucha dura evitar que los buenos programadores que están en tercero de informática no empiecen a trabajar sin acabar al menos la técnica, luego se eternizan como alumnos–.
Además, ¿no hablan tanto al “libre mercado”? Un buen programador no tiene problemas para encontrar puestos mejores. Un buen programador no está preocupado del “intrusismo”, si los “intrusos” son buenos programadores, bienvenidos sean.
Si en cambio no lo son no representan ningún problema para él, todo lo contrario, le quitan el trabajo que él no está interesado en hacer.
Y por último y aunque está fuera de las diez no podría dejar de ponerla
10bis. Si te dicen expresiones regulares y sólo tienes un problema
Yo he cometido todos esos “pecados”, y sigo cometiendo algunos. Pero intento dejar de hacerlo. Lo malo es que cuando ya deje de hacerlo tendré muchas más “pistas” que agregar a la lista, y así volveré al punto inicial nuevamente.
O quizás eso es justamente lo mejor de ser un programador.
Edición: Paco propone una que no sé cómo se me ha pasado:
10bis2. Consideras que ya eres suficientemente buen programador y que debes dedicarte a otras tareas como el análisis, diseño o planificación. La programación es una tarea secundaria y trivial que puede hacer cualquiera
No hay comentarios:
Publicar un comentario