Diez cosas que enfurecen a los programadores

Los programadores son un grupo bastante especial. Debido a su largo contacto con las computadoras, han desarrollado personalidades y temperamentos bastante similares. Por supuesto, como son personas, tienen su propia personalidad y también su mal genio. A continuación, veamos diez cosas que pueden enfurecer a los programadores. Por un lado, podemos ver los rasgos comunes de los programadores; por otro lado, también podemos ver sus defectos. De cualquier manera, espero que les sirvan de ayuda en su trabajo diario.

Décimo lugar: comentarios en el código

Los comentarios en el código son originalmente un buen hábito. Cuando un programador veterano guía a un novato, siempre le dice que debe escribir comentarios en el código. Entonces, los novatos, por supuesto, siguen las instrucciones del veterano. Sin embargo, es posible que tengan algunos malentendidos sobre los comentarios, así que a menudo vemos comentarios como los siguientes en el código:

Cada vez que ves comentarios así —que solo comentan el qué, no el porqué—, seguro que te enfureces. ¿Quién habrá escrito estos comentarios? No te calmarás hasta encontrar al responsable y regañarlo. Los comentarios deberían comunicar tu intención y tus ideas, no la sintaxis del programa, y existen para la legibilidad y el mantenimiento del código. Estos comentarios escritos por comentar claramente no son comentarios, sino una provocación; es innegable que enfurecen a cualquiera.

r = n/2;  //r是n的一半
 
 //循环，仅当r- n/r不大于t
 while ((r-n/r) <=t){
     //… …
     r = 0.5 * (r-n/r); // 设置r变量
 }

Noveno lugar: interrupciones

Justo cuando un programador está inmerso en la reflexión sobre un algoritmo, o está escribiendo código con un arranque de inspiración, ser interrumpido por otros es algo muy doloroso. Si lo interrumpen continuamente, puede ponerse irritable de inmediato. Quien interrumpe es muy descortés en esta situación. La persona interrumpida es como una llamada a función: al volver, necesita restaurar el contexto del punto de interrupción. Por supuesto, el ser humano no es una computadora; restaurar el contexto suele ser un proceso muy doloroso. En casos extremos, puede tener que retomar el hilo desde el principio e ir volviendo poco a poco hasta el punto de interrupción.

Por eso veo que algunos programadores, cuando necesitan estar en silencio y no ser molestados, o eligen ir a un lugar donde nadie pueda encontrarlos, o cuelgan sobre su escritorio un cartel que dice: "Estoy ejecutando el kernel del sistema, no se puede interrumpir, por favor no molesten, ¡gracias!". Se nota que interrumpir a un programador inmerso en su trabajo tiene un coste muy alto. Naturalmente, no son pocos los que se enfurecen por las interrupciones.

Octavo lugar: cambios en los requisitos

Esto seguramente no hace falta explicarlo mucho. Cualquier programador se siente impotente ante los cambios de requisitos. Una o dos veces aún se pueden aceptar, pero no hay quien aguante cambios constantes. Se dice que el desarrollo ágil tiene una metodología que permite a los programadores disfrutar de los cambios de requisitos; no sé si será cierto. Pero hoy te dicen que hagas un escritorio, mañana que conviertas el escritorio en una mesa de comedor, pasado mañana que conviertas la mesa en una cama doble, al día siguiente que conviertas la cama en una cabaña de madera, y luego que conviertas la cabaña en un rascacielos. Ay, cualquiera se enfurecería. Esas personas pueden tomar cualquier decisión en una reunión de 30 minutos, pero decenas de programadores necesitan cientos de horas de duro trabajo. Si fuera yo, quizás también necesitaría la ayuda de la bestia mítica "Cao Ni Ma" para desahogarme.

Sin embargo, esto también demuestra que los programadores no saben cómo comunicarse con los usuarios, y los usuarios tampoco saben cómo comunicarse con los programadores. Si un proyecto no tiene un intermediario (como un PM) que coordine, todo el proyecto puede ser un completo "diálogo de sordos"; tanto los usuarios como los programadores acabarán enfurecidos con el otro. Si tuviéramos que enumerar algunas cosas que enfurecen a los usuarios, probablemente la testarudez de los programadores de pensar solo desde la perspectiva de la implementación técnica también entraría en el top 5.

Séptimo lugar: gerentes que no entienden la tecnología

¿Acaso son pocos los casos en que un profano dirige a un experto? Lo que dice el jefe, sea correcto o no, es lo correcto; debemos obedecerlo. Aunque sea una decisión estúpida o errónea, tenemos que cumplirla. En realidad, a los programadores no les asusta que el gerente no entienda de tecnología; lo que más les asusta es que un gerente que no entiende de tecnología finja que entiende mucho. Lo más indignante es que, cuando discutes con argumentos para desafiar la autoridad del jefe, este te trata como a un bicho raro. Ay, con solo pensar en esos jefes, olvídate de insultarlos, hasta dan ganas de pegarles.

En realidad, el gerente no es más que un apoyo para el equipo; debería ayudar al equipo y resolverle los problemas, no darle órdenes. La gestión es realmente sencilla: si entiendes, ayuda a hacerlo; si no entiendes, confía en tus subordinados y dales libertad para trabajar. Lo peor es un gerente que no entiende de tecnología y encima no confía en sus subordinados. Ay, ese es un verdadero dolor para los programadores.

Sexto lugar: documentación de usuario

La documentación de usuario no debería dar tanto miedo. Estos documentos registran todo lo relacionado con el software que desarrollamos. Como no sabemos cuál es el nivel de conocimientos informáticos del usuario, al escribir estos documentos debemos asumir que el usuario no sabe absolutamente nada. Por eso hay que escribir el documento más completo posible con el lenguaje más claro y elegante. Incluso una operación de copiar y pegar puede requerir dividirla en cinco o seis pasos. Incluso una operación de configurar una dirección IP debe describirse paso a paso desde el menú de inicio. Para los programadores, que casi a diario usan el software que ellos mismos desarrollan, al final hasta pueden llegar a sentirlo con asco; pero aun así tienen que escribir estos documentos desde las partes más simples, lo que naturalmente los irrita. Si los programadores hacen esta documentación, el resultado probablemente sea muy malo. Por lo tanto, esta documentación de usuario debería ser redactada y mantenida por personal especializado en documentación.

Quinto lugar: falta de documentación

Como se dijo en el punto anterior, a los programadores no les gusta escribir documentación, y como el personal técnico generalmente no tiene muy buenas habilidades de expresión y redacción, la documentación suele quedar muy mal. Basta con ver la documentación de la comunidad de código abierto. Pero, por otro lado, lo que más enfada a nuestros queridos programadores es la falta de documentación. Claro que lo anterior era sobre la documentación de usuario; aquí hablamos de la documentación de desarrollo, como documentos de diseño, especificaciones funcionales, documentación de mantenimiento, etc. Aunque básicamente es lo mismo. En fin: por un lado, a nuestros programadores no les gusta escribir documentación; por otro lado, se quejan de que no hay documentación, de que hay muy poca o de que no se entiende. Jeje. Parece que hasta en las quejas hay recursividad. Se dice que el desarrollo ágil puede reducir la documentación en el desarrollo de software, y que pueden escribir código que parece documentación y diagramas; no sé si será cierto. Pero he oído a muchísimos programadores quejarse de que falta documentación o de que es muy mala; en este aspecto, la culpa es de los propios programadores.

Cuarto lugar: entorno de despliegue

Aunque los programadores desarrollan software, no sabemos en qué entorno se implementará o instalará nuestro programa: por ejemplo, diferencias en la red, diferencias en RAID, diferencias en BIOS, diferencias en los sistemas operativos (WinXP y Win2003), presencia o ausencia de antivirus, compatibilidad con otros programas, programas maliciosos o virus en el sistema, etc. Por supuesto, en cuanto tu software falla, ya sea problema del programa o del entorno, es tu problema y tienes que resolverlo todo. Así que los programadores no solo programan; muchas veces también tienen que hacer bien de administradores de sistemas. Cada vez que al final se confirma que el problema es por culpa del entorno, es inevitable que los programadores se llenen de resentimiento.

Tercer lugar: informes de problemas

"Mi software no funciona", "El programa da error". Cada vez que escuchamos informes de problemas como estos, los programadores sienten un gran dolor, porque ese tipo de informe no dice absolutamente nada, pero aun así el programador tiene que ocuparse del error. No hay una descripción clara del problema, no se explica cómo reproducirlo, y da la sensación de que te están interrogando. Incluso en ocasiones se mezcla un tono de desprecio o regaño. Por supuesto, los programadores suelen tener mucho carácter y no se doblegan ni con halagos ni con amenazas; así que cada vez que alguien reporta un problema con ese tono, no es raro que respondan con malas maneras y naturalmente luego ocurren cosas desagradables. Por eso necesitamos un departamento de atención al cliente que ayude a la comunicación entre los programadores y los usuarios.

Segundo lugar: los propios programadores

Quien enfurece a los programadores quizá sea el propio programador. Los programadores se desprecian unos a otros; en general, son arrogantes por su talento y siempre creen que son los mejores. Entre programadores discuten casi todos los días, y cuando discuten se encienden hasta ponerse rojos. Entre ellos, siempre terminan enfureciéndose unos a otros.

Diferencias de opinión sobre tecnología: por ejemplo, Linux vs Windows, VC++ vs VB, Vi vs Emacs, Java vs C++, PHP vs Ruby, etc., etc. Discuten por cualquier cosa.
Los veteranos menosprecian a los novatos. Siempre hay programadores que desprecian a otros, y al hablar usan un tono de arrogancia y regaño. Cuando un novato va a hacer una pregunta, los veteranos suelen tratarlo con frialdad e indiferencia.
No le guardan las apariencias al otro en lo técnico. No sé por qué, pero los programadores siempre dejan al otro sin salida; cada vez que oyen que alguien entiende mal una tecnología, les encanta señalarlo en voz alta y en público, usando el "error" del otro para mostrar su propia "erudición" y demostrar la "ignorancia" ajena.
Les gusta despreciar. Les gusta despreciar. En realidad, en este mundo nada es perfecto; todo tiene sus virtudes y sus defectos, y encontrarle pegas a algo es facilísimo. A los programadores les encanta despreciar a los demás. Miren lo que miren, siempre se fijan en las carencias ajenas y no en las virtudes. Sus muletillas habituales son "muy malo", "no sirve", etc.

Los programadores, acostumbrados a tratar con computadoras durante mucho tiempo, escriben código que la computadora ejecuta siempre obedientemente; con el tiempo desarrollan un carácter altivo que lo desprecia todo. Pero no se dan cuenta de que muchas cosas en este mundo no son tan simples como una computadora que, con tal de que le des las instrucciones correctas, funciona correctamente. Programadores, ¿cuándo van a madurar...?

Primer lugar: el código de los programadores

No importa cuán hermoso y clásico creas que son tu diseño y tu código en ese momento, después de un tiempo, si miras hacia atrás, inevitablemente pensarás que fuiste un necio. Por supuesto, cuando necesitas mantener el código de otros, seguro que maldices el código ajeno mientras lo mantienes. ¿Recuerdas lo fanfarrón que eras al discutir con otros lo perfecto que era tu diseño y tu código? Pues en menos de dos años, un recién graduado que mantenga tu código podrá señalar tus errores y hacerte perder completamente la cara. Jeje. Claro, también hay quienes siempre piensan que su diseño y su código son los mejores, pero eso es ver el problema con una mirada bastante estática. En el mundo de la programación todo cambia muy rápido; muchas cosas solo nos resultan familiares después de haberlas hecho, y solo cuando las conocemos bien sabemos cuál es el mejor método. Eso es un proceso gradual. Por lo tanto, cuando cada vez conoces mejor las cosas, al mirar atrás a los diseños y códigos que hiciste antes, inevitablemente notarás tu propia superficialidad y necedad; y al ver el diseño y el código de los demás, probablemente también empieces a maldecir.