1. Es un incentivo para aparecer.
2. Se llega a la más honesta comunicación.
3. Reduce las quejas sobre los salarios bajos.
Continuar leyendo ‘15 razones por las cuales el alcohol debe ser servido en el trabajo’
Etiqueta agregada: ‘razones
Todos deberían saber que leer tiene sus riesgos:
1.- Quienes leen mucho acaban ciegos. Primero son esas gafitas de intelectual, luego las de culo de vaso y acabas como Galdós o Borges, contratando a una tierna manceba que te lea a los pies de la cama.
2.- Quienes leen mucho acaban trastornados. Como don Quijote, o Cela. Una alumna mía me decía que hay por ahí un tonto ambulante que se quedó así de tanto estudiar. Al parecer se tomaba todo tipo de psicotrópicos para mantenerse despierto mientras leía y leía.
3.- Leer agota tu economía. Los libros son caros y no se pueden bajar con el emule. Los que están en internet son clásicos y por tanto largos, así que si los lees en la pantalla todavía te quedas más ciego (ver punto 1).
4.- Leer complica la vida doméstica. Acumular libros se convierte en una obsesión que requiere espacio, metros de estanterías desordenadas, dolorosas cajas en el trastero, mesitas de noche polvorientas… Con la amenaza de cónyuges o hijos: Elige, los libros o nosotros. Y esa pregunta estúpida de las visitas no lectoras: ¿Te los has leído todos?
5.- Leer complica la vida amorosa. ¿Todavías estás leyendo? Pues me duermo…
6.- La lectura suele ser fuente de toda infelicidad. Quienes no leen no tienen más punto de vista que el que les ofrece su cadena de televisión habitual, su peluquero, su estanquera o su compañero de cañas. No necesita contrastar visiones distintas de un hecho, ni ponerse en lugar del otro. Asume que la realidad es plana. Y es feliz.
7.- Los libros generan frustración. La lectura te muestra vidas que nunca llegarás a vivir y lugares que nunca conocerás. Te permite imaginar a los personajes y lugares de las historias del modo que tú quieres. Luego vienen los de Hollywood y te plantan al guapo de turno en unos paisajes de Nueva Zelanda que te cagas, y ya está, tu gozo imaginado en un pozo, porque cómo les explicas tú a los espectadores de la sala que lo que tú habías imaginado era mejor.
8.- La lectura es algo lento y repetitivo. A ver, ¿qué ha cambiado en la lectura en los últimos dos o tres milenios? ¿Leemos más rápido? ¿Se lee a través, renglón sí, renglón no? Nada. Siempre igual, una línea detrás de otra. Y encima hay que esperar más de una hora (una semana, un mes) para que nos cuenten el encuentro amoroso de una pareja, el remordimiento por un crimen, la frustración por una vida anodina, la conquista de una libertad.
9.- Leer no sirve para obtener admiración. Por si alguien no se ha enterado, ser buen lector no cotiza en la bolsa de la vida social. Que alguien cite a buenos lectores que salgan en la tele: … (silencio prolongado). Antes, con lo de mayo del 68 y todo eso, aún se ligaba citando a Camus, a Brecht, a Quevedo. Pero ahora, como no cites a Jaime Peñafiel…
10.- La lectura no está al alcance de todos. Digan lo que digan, el placer de leer está reservado a unos pocos. Son esos pocos los que gozan casi pecaminosamente cuando descifran un clásico, cuando sienten las pasiones que se imaginaron hace siglos para que les lleguen a ellos casi en exclusiva, cuando se quedan varios días en estado de shock después de leer buenas novelas, cuando se estremecen leyendo un poema, cuando lloran o ríen entre líneas, cuando recomiendan furtivos lecturas que no se venden en Carrefour, cuando no pueden salir de casa sin un libro en el bolsillo, cuando miden sus vidas por los libros que leyeron en cada época… Son una élite, peligrosa y exquisita, que procura captar miembros para su secta, pero que también sabe que muy pocos serán los elegidos. ¿Lo eres tú?
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.
Comentarios Recientes