12 señales de que eres un mal programador

Visto en Digg. Puede que no esté de acuerdo con todas, pero es una lectura interesante.

1. Java es todo lo que necesitas.
No ves la necesidad de usar ningún otro lenguaje, ¿por qué no se puede hacer todo con Java? No te importa ver código en Python o Ruby que logra en 10 lineas lo que llevaría varias hojas de código Java. Además, seguramente las nuevas características de la próxima versión del lenguaje lo arreglaran de todas formas. (Esto es aplicable a casi cualquier lenguaje, pero ocurre que entre la comunidad Java parece estar más extendida esta forma de pensar)

2. El término «enterprisey» (NT: se trata de un término sarcástico utilizado para designar productos complejos más allá de lo necesario) no te suena a broma.
«Enterprise» no es sólo una palabra, es una filosofía, una forma de vida, un camino a la iluminación. Cualquier cosa que pueda ser escrita, desplegada o actualizada con un trabajo mínimo es descartada como un juguete que no «escalará» para futuros usos. Mientras tanto la mayor parte del trabajo real en tu oficina se hace enviando hojas de cálculo en Excel mientras esperan a que termines de construir tu nueva visión corporativa.

3.Te opones férreamente a las funciones/métodos de más de 20 líneas de código.
(o 30 o 10 o cualquier otro número) Lo siento, algunas veces una función larga es justamente lo que necesitas. Normalmente las funciones cortas son más sencillas de entender, pero algunas veces se pueden expresar más fácilmente en una sola función más larga. El código no debería hacerse más complejo sólo para adecuarse a criterios arbitrarios.

4. «¡OH DIOS MÍO! ¡PATRONES!»
Los desarrolladores que buscan constantemente la forma de aplicar patrones a cualquier problema de código con el que se encuentran están añadiendo una complejidad innecesaria. Lejos de ser algo que busques, deberías sentirte mal cada vez que tienes que utilizar un patrón de diseño, significa que estás escribiendo código que hace las cosas más complicadas y que puede ser de dudosa utilidad. Pero, ¡ey!, tu código tiene patrones, bien por ti.

5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.
Hay montones de problemas en los que tienes que tener muy en cuenta el consumo de CPU (modelado/simulación, procesado de señales, kernels de sistemas operativos, etc), pero no es tu caso. Para la mayor parte de los desarrolladores de software sus principales problemas de rendimiento están relacionados con las bases de datos y la entrada/salida. El único efecto de optimizar tu código para mejorar el uso de CPU será disminuir en 2 milisegundos el tiempo necesario para la próxima consulta a la base de datos. Mientras tanto el desarrollo de la aplicación se hace más lento, no puedes hacer frente a los nuevos requerimientos y te encuentras con problemas serios de calidad. Pero al menos estás ahorrándote montones de ciclos de CPU… eventualmente.

6. Piensas que ninguna función/método debería tener más de un return.
Esta la he oído alguna que otra vez, y normalmente la razón que me dan es que el código es más sencillo de analizar. ¿Según quién? Yo encuentro más fácil de leer un código más simple, y normalmente el tener más de un return simplifica el código.

7. Tus usuarios son estúpidos. Realmente estúpidos.
Simplemente no puedes creer lo estúpidos que son, olvidándose constantemente de hacer las cosas más sencillas del mundo y cometiendo errores tontos al usar tu aplicación. Nunca has considerado que quizás es tu aplicación la que es estúpida porque eres incapaz de escribir software decente.

8. Te enorgulleces enormemente del gran volumen de código que escribes.
Ser productivo es bueno, desafortunadamente escribir montones de líneas de código no es lo mismo que ser productivo. Los usuarios nunca comentan «Guau, este programa puede ser difícil de usar y estar lleno de errores, pero al menos sé que hay un montón de código por debajo.» En lugar de ser productivo, generar toneladas de mal código retrasa a los demás desarrolladores y en el futuro su mantenimiento constituirá una pesada carga.

9. Copiar y pegar es genial, te ayuda a escribir código desacoplado.
Defiendes tu uso del copy paste con extraños argumentos sobre desacoplar código y eliminar dependencias, mientras ignoras el aumento del tiempo de mantenimiento y los problemas de duplicación de errores. A esto se le llama «racionalizar tus acciones».

10. Piensas que la gestión de errores consiste en capturar todas las excepciones, registrarlas, y continuar como si nada.
Eso no es gestionar errores, eso es ignorar errores y es el equivalente semántico al «on error next» de VB. Sólo porque hayas registrado el error en algún sitio no significa que lo estés tratando. Tratar errores es algo duro. Si no sabes qué hacer exactamente cuando te encuentras con un cierto error, simplemente deja que la excepción se propague y que un nivel más alto del código lo trate.

11. Modelas todo tu código en UML antes de escribirlo.
El modelado entusiasta de UML se lleva a cabo normalmente por aquellos que no escriben demasiado código, sino que se consideran arquitectos de software. Las herramientas de modelado atraen más a aquellos que piensan que el código se puede escribir en una sala de conferencias manipulando pequeños gráficos. Los gráficos no son el diseño, y nunca serán el diseño, para eso está el código.

12. Tu código borra datos importantes.
Escribiste un cierto código que se supone que debe sobrescribir los archivos de la aplicación con otros nuevos, pero se vuelve loco y borra todos los datos del usuario.

129 pensamientos en “12 señales de que eres un mal programador”

  1. La mayoría son del tipo «No hay que pasarse»

    Salvo quizá la 1) Quedarse con un sólo lenguaje, la 7) que los usuarios son estúpidos y 12) Tu programa borra datos importantes.

    Es lo que pasa cuando uno confunde las buenas prácticas con normas divinas. Lo que ha sacado es una lista de donde se cae más habitualmente por exceso.

    Por ejemplo los programadores recien salidos caen a menudo en 5) lo de ahorrar ciclos de CPU, se pasan dos días en ganar un 0.1% de velocidad, cuando el programa debería estar la semana pasada, y para colmo hacen un código ilegible.

    La 2), 3) y 4) («enterprisey», funciones de no más de 30 líneas y patrones «per tuti») son más propios de gente que lleva mucho tiempo metido en la empresa y se ha hecho a unas prácticas rutinarias.

    Y por cierto, en el 1) Quedarse con un sólo lenguaje, también se puede caer en el exceso en sentido contrario. Dominar un lenguaje y entorno de trabajo para trabajar con soltura cuesta tiempo (recordar la sintáxis, las funciones que hay para cada cosa etc), tampoco es buena idea que un proyecto tenga 27 lenguajes, ni que un programador salte de una a otro continuamente teniendo que repasar y mirar la ayuda cada dos líneas.

  2. He leido todo el post, todos los comentarios, sobre el uml no comento nada, estoy deacuerdo con lo que se ha dicho mil veces. Sobre el rendimiento decir que si no ves la forma mas optima de hacer algo es por falta de atencion o que en tal caso la optimizacion necesita de mucho tiempo y es imprescindible, digase por ejemplo en un software como photoshop.
    Quien conoce en mayor o menor medida muchos lenguajes sabe perfectamente que java no esta hecho para todo, el lenguaje que mas se aproxima a eso es c++ y tampoco puede cubrir todo, si os gusta python probad perl, prefiero entender en 20 lineas de cualquier lenguaje que una sola de perl que hagan lo mismo, los lenguajes de scripts estan para lo que estan, no hay sistemas operativos escritos en java ni en python.
    Patrones, si por favor hay mas gente en el mundo que necesita saber que es cada cosa, claro que todo sin abusar, los return uno o varios me es indiferente, normalmente uso uno, pero si en las busquedas dentro de bucles pongo otro, simplifica y la simplificacion siempre ayuda.
    Si en algun metodo o funcion necesitas mas de 30 lineas es o bien porque no lo estas programando bien o esta mal diseñado, desde que los gotos desaparecieron el mundo es mejor, el dia en el que no exista metodos de mas de 30 o 40 lineas el mundo sera mas feliz, entonces dara igual el numero de return.
    Sobre el 12 como coño se programa algo que borra todo?, desde mi punto de vista que un programa borre un fichero es como pensar en un cirujano, tienes que estar muy seguro de lo que se esta haciendo, si no, es mejor que lo haga otro.
    Sobre los usuarios, puede que tu software no tenga usuarios inutiles, pero entonces seran malintencionados, y es mejor limitar muy mucho lo que pueden hacer.
    Yo me siento orgulloso cuando consigo hacer las mismas cosas con menos codigo sin renunciar a la legibilidad, o cuando con un poco mas se amplia la funcionalidad considerablemente.
    El copy & paste es una barita magica para crear bugs, pero si no lo haces de vez en cuando que haces? te implementas tu mismo todas las funciones, metodos, apis, llamadas al sistema, y .. el sistema operativo? si no eres linus torval no me parece una buena idea.

  3. Pingback: Señales de que eres un mal programador (y no lo sabes) por Renato Covarrubias Romero

  4. Sobre lo de usar Java solamente, olvidas que en España, el 90% de los grandes clientes imponen sus propios frameworks (casi todos en Java y alguno en .NET) y no te dejan usar mejores soluciones, con lo cual supongo que no has currado mucho en este mundillo aún… Sigue soñando que es bonito.

  5. Yo añadiría a aquellos que sólo hacen consultas a una base de datos mediante procedimientos almacenados (la vieja escuela). Bienaventurados ellos que sus programas serán infinitamente más seguros y rápidos, y sin hablar de la facilidad de mantenimiento.

  6. Pingback: La hormiga de Möbius » System.out.println(”12 fallos de un mal programador”);

  7. La verdad es que hoy me siento decaido, y queria comentar mi propia experiencia. Hace años hubiera dicho que sí indiscutiblemente al punto 1. Java es todo lo que necesitas.

    Estuve programando en Java alla por el año 1998 con el JBuilder 3.0, colaborando con el Framework y a la vez «habia que comer» una aplicación de facturación para los clientes. Bien, después de 2 años y 4 personas colaborando, fuimos capaces de hacer un programa que iba lentísimo.

    Pero eso sí UML, programación 3 capas, la verdad es que aprendí mucho, pero a nivel de empresario fue una ruina o quizas no fue el momento, por la lentitud de la herramienta.

    Actualmente, hacía como 5 años que no tocaba Java la cosa ha evolucionado y bueno todo va rapidisimo, el Eclipse ni punto de comparación con el primero que vi.

    Sobre el: 3.Te opones férreamente a las funciones/métodos de más de 20 líneas de código.
    Bueno hay que ser un poco flexibles pero ciertamente hay «partir» o pensar si se puede partir cuando tienes 20 lineas.

    Sobre el punto 8. Te enorgulleces enormemente del gran volumen de código que escribes.
    y el
    9. Copiar y pegar es genial, te ayuda a escribir código desacoplado.

    Estoy totalmente en desacuerdo, me lo encuentro todos los dias cuando me tocar hacer alguna modificación, a mi modo de entender es dejadez del programador que lo ha creado.

    Disculpad por el desorden de este comentario.
    Saludos.

  8. Pingback: 12 señales de que eres un mal programador « Conocimiento Libre

  9. Hola a todos,
    hay cosas ciertas y otras que quiero comentar. Desde el punto de vista del codigo chapuza y diseños poco escalables, escribir código sin diseño es algo prehistorico y que en estos momentos no es viable. Los diseños en UML ayudan y es una forma tan válida como otra cualquiera de enteder a priori el código que luego vas a generar. Saber exáctamente los procedimeintos a utilizar no siempre es posible, aunque si los más importantes están reflejados en el diseño simplifica y acorta el tiempo de desarrollo. Como siempre un diseñador dee haber rpogramado tiempo para saber lo que se puede o no hacer en cada caso. De todas formas cosas dichas aquí son extensibles a .Net, etcetc.
    Un saludo

  10. Yo discrepo de la mayoría de puntos, aunque en algunos estoy de acuerdo, como el 6º, el del «return», XD.

    Esta lista está enfocada en programación orientada a objetos y más concretamente a Java, y que yo sepa ni Java es el único lenguaje de programación, ni la orientación a objetos el único paradigma de programación.

    Particularmente, yo trabajo con otros lenguajes tipo C y en sistemas críticos de tiempo real, y no uso patrones más que nada porque no existen como tales, por ejemplo, o lo que indica el punto número 5 lo rebato totalmente: los ciclos de CPU son críticos. Hoy en día estamos acostumbrados a tener el cojoordenador con el cojosistema operativo que nos resuelve esas «pequeñas incomodidades» como es el rendimiento o la respuesta de tu software.

    Aun así, me gusta la idea de hacer una lista de puntos que medio-indiquen si un programador es bueno, regular, malo, o ha hecho el curso de IBM de programación por fascículos, XDD

    Saludos a todos.

  11. Hombre, Miguel Angel! creo que soy uno de esos 4 frikis de los que hablas XD. La verdad es que nos fuimos bastante de la olla, supongo que por la falta de experiencia. Lo peor es que en estos últimos años me he vuelto a encontrar en situaciones similares: chavales de 28 o 29 años que se creen gurús porque han comprado y hojeado (no leído) un par de libros de UML y patrones, y que acaban haciendo auténticos destrozos. Ese era yo hace diez años.

    En cuanto a las 12 señales estoy de acuerdo con casi todas, excepto la 3 (la de las líneas por funcion) y la 4 (la de los patrones).

  12. Pingback: foroFriki » 12 señales de que eres un mal programador

  13. Estoy de acuerdo en muchos de los puntos, pero no con el 6 (varios return),como ya ha comentado alguien. Me da que pensar que quiza no has pasado por la desagradable experiencia de mantener codigo ajeno. Efectivamente, puede ser mas facil de entender, y desde luego de programar, pero a la hora de mantener una funcion grande (mas de 20 o 30 lineas :-|), que tiene varios returns puede ser una pesadilla si , por ejemplo, quieres hacer algo siempre que se salga de la funcion.

  14. Esto debe estar escrito por alguien que sabe programar pero no sabe informática. Me explico.

    Incluir en esta lista de errores el modelado y el uso de patrones responde a que esta lista la ha creado alguien que o los desconoce o no sabe usarlos.

    Programar sin tener un diseño previo en Ingenieria de software se llama caos.

    Los patrones simplifican las cosas y facilitan la reutilización de código. Otra cosa es no saber usarlos.

    Serán cosas mías pero en sitios dónde se crean aplicaciones (America, India, Japón) se utilizan técnicas de modelado y patrones.

    Ignorar la importancia de los ciclos de CPU es porque se ignoran las bases de la informática. Si no, para qué incorporar en las CPUs un branch predictor si los ciclos vacios no importan? Esto está relacionado con conceptos como rendimiento, eficiencia…

    Esto producirá programas más baratos y que funciones de ahí a que valgan algo «informáticamente» hablando es otra cosa.

  15. Creo, que el autor del post los puntos que plantea son cuando se llevan a un extremo. No creo que hayan reglas fijas al momento de programar, en ese sentido: «programar es más un arte que se apoya en la técnica». Quizas por eso va ser muy dificil encontrar para un mismo problema dos programas exactamente iguales.
    Finalmente, toda esta discusión la encuentro super valiosa.

  16. Pingback: Picando Código

  17. @Jose Luis
    A Linux distribution where ALL programs are written in perl,
    por si no has entendido lo que significa:
    una distribución linux (escrita en C y asm) donde todos los programas estan escritos en perl.
    Pero gracias, no la conocía.
    @Zootropo
    una pregunta, ¿la maquina virtual desde la que se ejecuta todo el sistema en que esta escrita?
    Tampoco conocía JavaOS, me parece una gran idea, quizás algún día exista una arquitectura nativa para java, y poder hacer un sistema operativo en java, en ese momento todo el software java se ejecutara mas rápido.

  18. «Lejos de ser algo que busques, deberías sentirte mal cada vez que tienes que utilizar un patrón de diseño, significa que estás escribiendo código que hace las cosas más complicadas y que puede ser de dudosa utilidad.»

    Es cierto que no se puede aplicar patrones a discreción, pero de la impresión de que está en contra de ellos en absoluto. Si es así… ¿para qué coño sirven los patrones? Díselo a los ingenieros, a los Gamma y 4F, que han escrito muchos libros.

    No creo que sean «de tan poca utilidad», entonces, los patrones.

  19. Sin duda leyendo lo referente a patrones, UML y eficiencia en cuanto a «programas que tratan simplemente con una base de datos» me dan la certera idea de que quien a escrito esto ni siquiera es ingeniero. Será un efepín o ni siquiera eso. Así que de grandes proyectos ni idea.

    En los demás puntos… reconozco que no le falta razón.

  20. Yo tengo unas reglas que no dice si eres un buen programador, pero desde luego que cuando alguien las incumple esta claro que es de lo malos:

    1.- Todo el codigo debe ir formateado, da igual que prefieras poner las llaves asi
    Algo {
    ..
    }
    que asi
    Algo
    {
    ..
    }
    pero que exista un formato.

    2.- Nombrar las variables para recorrer bucles con nombres cortos, a poder ser con una letra, y empezando por i,j,k,… y el resto con nombres algo mas largos.

    3.- No mezclar paradigmas en un lenguaje y menos en un mismo modulo (sobre todo en C++), si estas con Objetos, no pases punteros a funciones.

    4.- Hacer comentarios breves y precisos de cada función o método que no tenga un nombre que la describa bien.

    5.- Seguir la convención de java de unir varias palabras poniendo la primera letra de las palabras en mayuscula salvo que sea la primera porque entonces dependera de lo que se este nombrando, o usar ‘_’ como separador de palabras, pero usar algo!, aun sigo viendo código donde se lo pasan por el forro por raro que parezca.

    6.- No poner nombre kilometricos a variables ni funciones ni métodos, abreviar cuando sean muy largos.

    En realidad no son reglas, solo sentido común..

  21. Para Luis:

    Sólo comentarte que no confundas en tu punto 3, paradigmas y formas de implementación. En C++ estas usando el paradigma de Orientacion a Objetos, o podrías usar el paradigma de programación imperativa, tanto si usas punteros en ambos casos como si no. Paradigmas pueden ser el paradigma de programación Orientado a Objetos, el Imperativo, el Funcional, el de Programación Lógica, el de Programación Orientado a Restricciones, el Relacional, etc.

    En cuanto al punto 5, ¿por qué la convención de Java? ¿Sabes lo que dijo Tanenbaum hace mucho tiempo? Pseudocito porque no me acuerdo bien de las palabras concretas: «lo mejor de los estándares es que hay muchos entre los que puedes elegir».

    Es decir, que las convenciones hay miles y cada uno creerá más conveniente unas u otras, y esto sí que es de sentido común.

    Saludos

  22. Me parece bien que no aceptes una crítica al diseño del blog, pero me parece mal que la censures. O obligas a registrarse para comentar o no hagas perder el tiempo a la gente y pones en un cartelito en algún lugar de la web que moderas los comentarios, sean de la índole que sean o añade una razón más para la lista de señales por las que eres un mal programador: no escuchar críticas desinteresadas sobre el producto.

  23. Me equivoqué. Lo que puse antes era para David (dos comentarios antes del mio anterior a éste).

    Sorry for the inconveniences.

    Por cierto, ¿está subiendo el tono de la «discusión» o sólo me lo parece a mi? XD

    Saludos

  24. Manolo. Ese comentario se ha borrado porque no tenía absolutamente nada que ver con el tema de la entrada (como este, pero que se le va a hacer)

    Para quejas, sugerencias, insultos, peticiones de adopción, proposiciones indecentes, y todo lo demás está mi correo que puedes encontrar en la sección Contacto.

    ¿No te ha llegado el mail?

  25. @sebas
    ¿Te refieres a mí?

    @pobrecito hablador
    Pues a eso me referia sobre los estandares, hay muchos, y no es mala idea escoger uno, parecera una estupidez cuando se esta hablando de uml y su necesidad, pero al nivel mas bajo no es dificil ver como hay gente que no usa NINGUN estandar, ni nada con cierta logica o coherencia.

  26. De acuerdo en todos, sobre todo en el primero. Yo fuí programador Java mucho tiempo y conocí Ruby y bueno francamente ahora digo: «que pereza Java». Ha esta lista le falta un punto importante: «No escribes pruebas automatizadas de tu código». Eso es fundamental… y en Java… con un framework como Struts o Hibernate o Spring… es una lidia.

  27. Yo siempre programo orientado a objetos, mas que uml hago bosquejos, de que va para aca y para alla y quienes lo usan =P

    siempre uso funciones, algunas muy largas se pueden separar en varias mas pequeñas que pueden ser reutilizadas para otros fines

    el acceso y manejo de datos desde Bases de datos los gestiono con un par de objetos, uno que hace la autenticacion y pelea con la BD y el otro que maneja las querys y results y me muestra las excepciones sin asesinar la ejecucion del programa, con error en mano es mas facil debuggear o indicarle al usuario que esta metiendo la pata (ya que por mucho que uno los instruya siempre encontraran la forma de hacerlo)

    yo programo en PHP, por lo que para las interfaces hago plantillas y para el estilo CSS ahi no uso copy paste, simplemente invoco funciones y clases. Hacer una interface nueva me toma 3 lineas, pero en las funciones hay muchas muchas lineas que se encargan de formarla y manejar los eventos

  28. Pingback: 12 Señales de que programas mal!

  29. Pingback: Actualidad, Entretenimiento y Humor » 12 Señales de que programas mal!

  30. Pingback: 12 Señales De Que Eres Un Mal Programador « GigaBriones | La Informatica Nunca Fue Tan Sencilla ; )

  31. Jaja, creo que las criticas carecen de objetivos comunes. El criticar algo que no sabemos que es. Me refiero a que se esta criticando a unas reglas de programación sin conocer de que algoritmo se trata. Se quiere hacer recetas de programación!! NO. No se puede hacer recetas de programación. Depende de las condiciones del algoritmo. Depende del lenguaje.
    El punto de UML es muy importante. UML es parte de documentación y no solo describe clases. Existe muchos otros diagramas en UML. UML es importante, forma parte de la documentación, ayuda a la logica del planteamiento del código y punto.
    Ese otro punto de que eres un inútil si te tienen que testear no estoy de acuerdo. Es lógico que alguien tenga que hacer pruebas a tu código. Tu no eres un dios para hacer todo un sistema completamente solo. El programador no hace al sistema, lo hacen todos, inclusive hasta el usuario!

    saludos

  32. Pingback: Actualidad, Entretenimiento y Humor » 12 Señales de que programas mal!

  33. Pingback: » 12 señales para saber si eres malo programando

  34. */———————————————-*
    Al González
    Yo agregaría esta:
    13. Le llamas «librerías» a las bibliotecas.
    Saludos.

    Al González.
    Fundador de Programadores Delphi de México.
    */———————————————-*
    Hola a todos…
    muy bueno el post.. estoy de acuerdo con algunas cosas y con otras no.. por ejemplo.. lo de los usuarios estupidos y que sin usuarios la programacion estaria mejor.. que mejor va a estar??.. sin usuarios no exitiria la programacion!! asi de sencillo.. lo que pasa es que es mas facil escribir un codigo que uno entienda a escribir un codigo que sea entendible y estable.. lo del un solo return por funcion me parece algo tonto aunque siempre depende del codigo que estes haciendo.. UML lo odio pero tengo que reconocer que siempre se debe tener un mapa mental asi sea basico de lo que uno va a hacer antes de escribir codigo.. y Al en cuanto lo de libreria y biblioteca creo que el tratar de ser tan puristas lo que hace es desviar lo esencial del tema.. no creo que porque un programador llame a una biblioteca libreria, solo por ese hecho.. sea mal programador.. estamos de acuerdo que todo viene de la traduccion «library».. pareciera que es libreria cuando realmente es biblioteca.. libreria seria algo como books shop o tiendas de libros.. pero no creo que esa sea un punto a favor de que alguien sea mal programador.. sino todos somos malos porque en algun momento deciamos «libreria» jajaja..

    Saludos!

  35. «»Papel y boli son las mejores herramientas que existen para la programación»»

    Estoy completamente de acuerdo con esto 🙂

    Por otro lado, yo opino que las funciones, métodos tienen que ser lo más simplistas y cortos posibles, y nada de ser mal programador al pensar eso

  36. Pingback: kuro » Archivo del weblog » 12 señales de que eres un mal programador

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.