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 comentarios en «12 señales de que eres un mal programador»

  1. Pingback: Listas de consejos para programadores | Móchate

  2. Pingback: 12 seniales de que no eres un buen programador… « Mariobalu’s Weblog

  3. Simpático el post.
    Perdón, yo programo para usuarios tontos, los inteligentes hacen sus propios programas, y precisamente poniéndome en el lugar de un usuario tonto trato de atajar la mayor cantidad de errores posibles y al mismo tiempo hacer el programa lo más fácil posible de usar, de eso se trata o no?

  4. Yo creo que el modelado no es exclusivo de un programador y mucho menos de alguien de sistemas. El modelar es expresar una idea y seguir un flujo que te puede ayudar a encontrar consistencias e inconsistencias en una propuesta.
    El modelado no debe ser una interpretación de algo que se llevará a código máquina, debe pensarse también como un análisis y propuesta que se le hace a una persona que no conoce de sistemas pero entiende de forma gráfica los pasos que se requieren para concluir una solución automatizada por código máquina.

  5. Pingback: dvilchez.net » Blog Archive » Algunos links

  6. Los punteros en C son cosa de diversion,

    char *ptr1 = «hola puntero»;
    char **ptr2 = 0;

    ptr2 = &ptr1;

    cout << *ptr2 << endl;
    printf(«%s», ptr1 );

    Creo que es fundamental la imaginacion primero para dominar la tecnica.

  7. Que tal, soy un «pequeño» programador y digo pequeño por que no me considero un gran programador como aquellos que han contribuido a hacer del software un arte, y digo que es un arte por q un conocedor de programacion quedaria complacido al ver el codigo de una aplicacion al que no se le pueda aplicar ninguna optimizacion (ojo no es agregar cosas nuevas es mejorar el codigo q hace algo), bueno pasando a los puntos, no recuerdo q numero sea pero el punto q habla de multiples returns (mas de uno) dando mi opinion personal los multiples returns son validos siempre y en todo lugar, claro si se nesecitan, usulmente siempre empleo dos valores, el aceptado y uno especial que indica error, simple y sencillo (no me gusta hacer que las excepciones se propaguen mas de un nivel) no se en donde lo lei o a quien se lo escuche, pero segun se es de buena «etiqueta» controlar la mayor cantidad de errores mediante ifs o casos, debido a creo segun mi logica que le costara mas «trabajo» al ordenador identificar una excepcion que evaluar un if.
    Bueno esa es mi opinion, y sobre los UMLs son de gran ayuda si se saben utilizar, si no mejor con unos simples rayones bastaria para hacer algo «mediano»…
    Saludos a todos, espero haber aclarado mi punto de vista (cosa que dudo), pero al menos he expresado mi humilde opinion.

  8. Bueno creo me aplica la 9 , 10 . pero eso es visto desde otra optica buena y optima que es si tu copias un codigo se supone que esta bien elaborado y lo probaste y esta bien , no te va a generar errores .
    repecto a exceptar el error con un on error resume next creo q debe ser utilizado ya por un plugin o active x o un control que se salga de la manos del programador , bueno aqui hablando de VB y Delphi

  9. Creo que la variedad de cosas que fue desarrollando son algo importante para su experiencia en los distintos programas, seria bueno poder entender un poco mas de las herramientas de desarrollo para sistemas operativos… pero creo que esta proximo a desarrollar un sistema operativo propio y de marca sudamericana jaja.

  10. Al final la felicidad está en el equilibrio

    El estilo o el método no pueden imponerse a la finalidad a toda costa

    Y el fin no puede ser una excusa para no usar ningún estilo o método.

    La clave está en el termino medio en función del contexto.

    @E_Barrero

  11. La verdad este post ha sido una cachetada para mi, me voy a poner las pilas, me parece que gran parte de lo que dicen aqui es cierto… pero lo de patrones y UML lo considero excelente cuando se dispone a hacer medianos o grande trabajos y sobre todo en programas orientado a objetos… si se desean hacer controladores para impresoras o algo parecido no creo que aplique mucho el uml

  12. TOTALMENTE de acuerdo con la 1. Es increible ver la cantidad de programadores malos que hay en JAVA, saben poco o nada de arquitectura de ordenadores, manejo de memoria y sistemas operativos. Le tienen terror a un puntero y desprecian a los lenguajes especializados (en parte, porque puden ser muchisimo mejores que JAVA). Creo que en la universidad hay que volver a insistir con el cabron pero poderoso c/c++

  13. Creo que añadiría el clásico de «No añadir comentarios… por que ya se entiende.» Esto es una putada cuando el software pasa futuramente a manos de otro programador que no sabe ni por donde empezar por que no hay ni una sola linea de comentarios o añade comentarios como

    /*aqui empieza x*/
    /*aqui termina x*/

  14. Pingback: ¿Eres un Mal Programador? | cyfuss

  15. Pingback: ¿Eres un mal programador? - Informática

  16. Es verdad, creo que ser un buen programador consiste en mantener la mente abierta a posibilidades de usar nuevos lenguajes de programacion, reutilizar codigo y ejecutar soluciones sencillas pensando siempre en la escalibilidad del software.

    Por otro lado realizar diagramas como UML me parece una herramienta importnate y va dentro de la documentacion de tu software, te ayuda a mostrar a otros programadores la manera en la que funciona y en un futuro hacer mas practiva la planeacion de una escalibilidad, lo cual se traduce en dinero para el programador en poco tiempo. Me parece importante realizarlo, aun que no hacerlo tampoco genera mucho conflicto.

    Saludos.

Responder a Dorian Cancelar respuesta

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