Diez señales de que no eres tan buen programador como piensas
Diez señales de que no eres tan buen programador como piensas
Estas convencido que eres “muy buen programador”.
En general los buenos programadores interactuan y trabajan mucho con el codigo de otros programadores, y siempre hay alguien que tiene soluciones mas 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 el.
Reconoces inmediatamente a Jobs, Gates o Torvalds pero no sabes quienes son y/o que han hecho Turing “ademas de su modelo matematico tan conocido “, von Neumman “ademas de su famosa definicion de “arquitectura” “, Dijkstra, Knuth, Wirth, Kernighan, Ritchie, Engelbart, Corbato, Hoare, Minsky
ÃÂÂÂĉ€šÃ‚¿Irias a un medico que no sabe que ha hecho Pasteur o Ramon y Cajal? Pues eso. (No significa que saber la vida de esos personajes garantiza ser buen medico, pero un buen medico seguro que lee mucho sobre su profesion, si no sabe es que ni siquiera se preocupa en leer mas alla de lo que le exigieron en la carrera, y que ademas se le olvido una gran parte).
A primera vista del codigo de programas grandes de otras personas dices “vaya mierda de codigo, muy complicado, yo lo puedo hacer mejor”.
En general los programas grandes son desarrollados por muchas personas, cada una con su vision “a veces contradictoria con otros–y estilo propio. Aunque haya sido desarrollado por una sola persona, seguramente esta evoluciono y cambio “en general a mejor–durante el desarrollo. Tambien van cambiando la “realidad” y las herramientas, lo que implica que las soluciones no son siempre las mismas. Ademas el software se hace cada vez mas 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, ademas de tener muy claro que una solo persona es incapaz de desarrollar grandes programas por si sola, por eso nunca desmereceria el trabajo de otros sin un conocimiento exhaustivo del programa y sus problemas asociados (y lo mas seguro es que envie parches o soluciones mejores).
Justificas que tu codigo 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 solo binario “.
Asi te encuentras con codigo 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 indices, ningun comentario o lo que es peor, exceso de comentarios del tipo /* asigno 0 a la variable i */.
Como las novelas, ÃÂÂÂĉ€šÃ‚¿alguien leeria novelas sin ningun tipo de estructura de oraciones, parrafos y capitulos? ÃÂÂÂĉ€šÃ‚¿o sin signos de puntuacion o escritas en lenguaje de telefonos moviles? Si uno sabe de antemano que su codigo sera revisado y modificado por otras personas se plantea escribirlo de otra forma, mas acorde con el estilo de cada lenguaje y que sea agradable de leer.
ÃÂÂÂĮ’â€Â°sta es una gran ventaja de los programadores de software libre, ademas que se programa pensando en que otros lo miraran, en general ya ocurre lo que esta explicado en #2: se aprende mucho mirando el codigo de otros.
No sabrias definir en pocas palabras que es la programacion estructurada, ni sus relaciones y ventajas/desventajas con las arquitecturas y diseño del hardware.
Pues eso, un buen programador sabria explicar que las estructuras de control tienen un solo 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 codigo “ademas de las ventajas obvias del codigo fuente de alto nivel estructurado “.
Afirmas “el ultimo lenguaje/librerias/framework XYZ es el mejor”. O que “C y ensamblador desapareceran”, o peor aun, “el C++ reemplazara al C en los sistemas operativos”.
Cualquiera que haya vivido o leido sobre las diferentes tecnologias y soluciones informaticas entendera muy bien lo que explica Brooks en “no existe la bala de plata” (There is no silver bullet, mejor traducido como “no hay soluciones magicas”). Cada lenguaje ademas 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 asignacion dinamica de memoria–que se puede hace con C son casi imposibles o tan costosos que no merece la pena en lenguajes como Java. Aun mas, hay cosas necesarias en determinados programas que solo 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 refran para el que solo tiene un martillo todo lo que ve son clavos. La informatica y programacion es mucho mas amplio que programar sistemas de facturacion o paginas web.
Te dicen que puedes tener una race condition en tu codigo y pones cara de pasmado.
La programacion de sistemas modernos es cada vez mas compleja, lo que hace que habitualmente se usen modelos de multiprogramacion, programacion concurrente y programacion distribuida. Incluso la programacion web es un ejemplo tipico de multiprogramacion. Todos esos modelos tienen asociados los problemas de concurrencia por comparticion 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 mas dificiles de aprender, lo que solo se logra con el estudio de los problemas fundamentales y mucha practica.
Piensas que en la universidad deberian enseñar Java desde el primer curso y que enseñar Pascal no tiene sentido.
Este es el tipico argumento de los que piensan que la universidad solo debe enseñar lo que “demanda el mercado”, o aun peor, que el o ella solo debe aprender lo que demanda su mercado.
El primer objetivo cuando se empieza a programar es aprender que es un algoritmo, como se representa en un lenguaje de alto nivel, estructurado, secuencial e imperativo “es el modelo mas usado y con mas metodos formales de diseño y verificacion “. 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 mas complejas solo introducen problemas y ruido en el aprendizaje, y lo que es peor, introduce vicios que luego son muy dificiles de eliminar.
Te han explicado alguna que tu codigo quizas se ejecute mas rapido si lo compilas para reducir el tamaño antes que optimizar codigo y has pensado que te engañaban.
Asi como esta enunciado parece una tonteria, pero solo podrian entenderlo los que tienen un conocimiento mas profundo de los que conocen a la arquitectura del hardware que ejecutan al programa. Esto significa conocimientos de gestion de memoria virtual, memoria cache, caracteristicas del TLB, etc. (De hecho este es un caso real, el nucleo del Linux, la velocidad de los procesadores se incremento notablemente mas rapido que la memoria RAM, por lo que el papel de las tecnicas de cache crecio en relevancia).
Eres parte del movimiento mileurista, o te quejas del intrusismo laboral.
No conozco a ningun buen programador que cobre mil euros al mes “y conozco a muchisimos, la ventaja de haber sido su profesor “. El paro de los programadores es casi cero “casi diria que negativo en Balears, es una lucha dura evitar que los buenos programadores que estan en tercero de informatica no empiecen a trabajar sin acabar al menos la tecnica, luego se eternizan como alumnos “.
Ademas, ÃÂÂÂĉ€šÃ‚¿no hablan tanto al “libre mercado”? Un buen programador no tiene problemas para encontrar puestos mejores. Un buen programador no esta preocupado del “intrusismo”, si los “intrusos” son buenos programadores, bienvenidos sean.
Si en cambio no lo son no representan ningun problema para el, todo lo contrario, le quitan el trabajo que el no esta interesado en hacer.
diez señales que no eres tan listo como crees
Deja Tu Comentario o Tus Agradecimientos: