Las cosas que no soporto que diga un programador

…y quizás tampoco las soportan los demás programadores.

En mi ordenador funciona

Si el código no funciona en un ordenador con toda las dependencias adecuadas instaladas es un error de tu programa, sin dudas, no hay excusas. Nunca digas esta frase, sólo demuestra que todavía no estás preparado ni para asumir la responsabilidad de tu propio código. Si eres alumno demuestra que no te interesa aprender sólo aprobar con el menor esfuerzo posible… además de tomar como tonto al profesor, como si nunca hubiese oído esta excusa (la oímos decenas de veces cada vez que se presentan prácticas).

El programa peta/se cuelga/no funciona ¿qué es?

Otro error típico, sobre todo de alumnos y jóvenes que preguntan al profesor o a un compañero. Si tú que conoces bien tu código no puedes encontrar el error, ¿cómo pretendes que otro te lo arregle sin conocer el mínimo detalle? Siempre tienes que ir con el código en cuestión, indicando la función o la línea donde falla y en qué condiciones. Si no lo haces así demuestra que todavía eres incapaz de analizar tu propio código. Un buen programador es capaz de analizar y estudiar cualquier código, algunos les puede costar minutos, otros muchas horas, pero es esencial saber hacerlo. Se aprende con mucha práctica, pero hay que comenzar con el código de uno mismo.

Pero si pasa los tests

Desde que se empezó a hablar de test units parece que algunos lo toman con el resultado de los dioses. Pero no, un test sólo verifica los bugs ya detectados o los que se imaginó el que los programó. Seguramente no consideró todos los posibles fallos con las diferentes condiciones que se pueden dar en el código que verifica. Sobre todo si es de un código que todavía no existe y que debe ser programado por otras personas. Por ello no es excusa que pase el test, en todo caso hay que pedir que se mejore el test con el caso descubierto en tu código. Mejor aún si tú mismo lo haces.

Eso no me lo enseñaron

No puedes ser espectador pasivo de tu aprendizaje ni esperar que los demás sean los responsables de enseñarte todo lo que necesitas aprender para cada una de tus tareas como programador. Además es imposible que en unos pocos años de estudio puedas aprender todas las cosas que necesitarás durantes las décadas futuras en tu profesión. Es cierto que muchas cosas que deberían darse no se estudian (y que también critico, a veces chillando por la universidad) pero una respuesta así indica que no asumes responsabilidad de tus conocimientos. Quizás peor, que no te enteraste qué es lo que debes aprender, un psicólogo te explicaría que es “deficiencia meta cognitiva”. En todo caso sólo di “no lo conocía” o “no se me ocurrió, ahora mismo me pongo”.

Pero el código funciona

Esta es una respuesta también muy habitual entre estudiantes y programadores novatos. Es como si un novelista respondiese a la mala crítica con un “pero si al final el mayordomo era el asesino, se entiende”. Se da en dos situaciones diferentes:

  • El código es ilegible: Hay programadores que todavía piensan que los lenguajes de alto nivel se hacen para los ordenadores no para los humanos. Pero no es así, llevamos 70 años diseñando y desarrollando lenguajes de alto nivel principalmente para facilitar el trabajo a las personas, y no sólo al programador original, sobre todo a los demás que tienen que entender o modificar el programa. Una de las condiciones fundamentales de todo programador es que su programa se legible, que sea “fácil y agradable de leer”. Hay novelas que son fáciles de leer, otras que son complejas, hay cortas y otras largas y pesadas, pero todas respetan normas básicas: sintaxis, gramática, oraciones con sustantivo verbo y objeto, limitaciones de adjetivos, puntuación, párrafos, separación entre palabras, líneas, párrafos y bordes de la página. El código fuente de un programa debe ser similar, hay normas generales (por ejemplo espaciado, sangrado, nombres de funciones variables, ficheros, etc.) y otras que son “idiomáticas” de cada lenguaje o de programadores.Lo fundamental es aprender esas normas, respetar tantos las generales como las particulares. Si no lo haces no sólo demuestra la incapacidad como programador, también una falta de respeto a los que tendrán que analizar tu código (sean estos los colegas o los profesores que te tienen que poner una nota).
  • La solución es inadecuada: Muchas veces recurren a soluciones que no sólo no son óptimas, también las peores de su clase. Por ejemplo re-implementar un ordenamiento de burbuja cuando tienen la función qsort(), o una búsqueda secuencial cuando el array está ordenado (los dos últimos son problemas de no recurrir a la menor complejidad de ejecución bien conocidas), o hacer una espera activa cuando tienen primitivas sencillas con bloqueo, etc. En la “ciencias de la computación” se estudian estos temas, algunos de ellos son fundamentales y de conocimiento obligatorio. No sirve que el programa funcione para un caso concreto, debe funcionar para todos los casos previstos y con la eficiencia “formal” bien conocida en el área. Conocer esos temas es parte del proceso de aprendizaje de un programador, si alguien te indica que la solución es errónea quizás pueda estar equivocado, pero nunca la excusa puede ser “pero funciona”.

Vaya mierda de código, debería estar programado con ponga_aquí_las_últimas_tecnologías_o_frameworks

Es el típico error que hemos cometido todos. Normalmente se hace sin tener en cuenta las condiciones del momento en que comenzó a desarrollarse, los requerimientos iniciales, la tecnología y recursos disponible, ni la multitud de limitaciones que tienen todos los proyectos. Además, el estado actual de un proyecto es la evolución durante años de programadores, tecnologías y objetivos cambiantes. Cada uno de estos elementos aporta a la deuda tecnológica, tú también generarás la misma deuda, todos los hacemos.

Así que nunca sueltes esta frase ligeramente, sobre todo si vas a una empresa, solo demostrarás que además de ignorante no tienes respeto por el trabajo de tus colegas. Quizás el código realmente sea malo, pero antes de decir una palabra espera un tiempo, aprende de su historia, y si aún así piensas que puede mejorarse propón la solución, o mejor, envía el parche.

Un secreto: cuando los programadores oímos a otro soltar esta frase de un código que ni conoce pensamos “no podía faltar el gilipollas”. No hagas de gilipollas.

Yo hubiese usado ponga_aquí_la_librería_de_moda

Si dices esto es porque alguien te preguntó que te parece lo que implementó. Decirle que hubieses usado otra librería ya no ayuda y quizás estés equivocado o no conoces todos los detalles. Es mejor analizar antes, proponer cambios concretos y reservar esta frase sólo si no hay una solución adecuada (aunque muy raro que no haya soluciones). Nunca nunca nunca sueltes esta frase sólo por ver las primeras líneas de “include” o “package”.

Yo hubiese desarrollado un nivel intermedio de servicios ponga_aquí_el_formato_de_moda

Es el típico ejemplo del programador entusiasmado que tiende a la “sobre ingeniería” y aplicar en un proyecto todas las técnicas y palabros que aprendió o leyó. Pero una una ingeniería se basa en hacer las cosas en su justa simplicidad, agregar servicios y capas intermedias con formatos de intercambio (que requieren conversiones y serializaciones/deserializaciones, antes de ayer era binario, ayer era XML, hoy es JSON, mañana quién sabe) muy pocas veces está justificado y casi nunca elimina complejidad, todo lo contrario. Lo que suelen añadir es complejidad, latencias, consumo, necesidad de recursos y más administración.

Depende del tipo de proyecto sí que es necesario desarrollar una capa de traducción de este tipo, por ejemplo cuando haces el backend/API de servidor para apps móviles. En estos casos la capa es casi un objetivo y requerimiento inicial del desarrollo, no una idea creativa para aumentar la simplicidad de desarrollo y mantenimiento.

Intenta mantener el programa lo suficientemente simple para que se cumplan los plazos y la complejidad esté controlada, si el proyecto crece y necesita agregar capas y servicios se hará en su momento. En todo caso deberías preocuparte más de la estructura de datos: que sean simples y flexibles para expandirlas y usarla de otras maneras. Y si aún así te parece que una capa intermedia con traducción es formatos es necesaria, consúltalo antes con los programadores más expertos. Nunca lo plantees como primera opción, suele generar unos :roll: importantes.

La universidad debería enseñar ponga_aquí_la_última_moda

De este tema ya escribí varias veces, la última en Lo que se aprende, o debería, en la carrera de informática, pero insisto, el tiempo es limitado, no se pueden aprender todas las tecnologías que podrías encontrarte en tu carrera profesional. Antes eran cinco años, ahora cuatro, y ya hay una ley para que sea de tres. Ni en las mejores universidades del mundo podrán enseñarte todo lo que cree importante cada uno de los “actores del mercado”, si fuese tan sencillo las currículas no serían tema de debate y cambios continuos hasta en la ACM.

Por otro lado las “tecnologías de programación” no cambian tan radicalmente, muchas veces se usan ideas que ya se estudiaron y desarrollaron antes. Por ejemplo el tema de concurrencia tan estudiado en sistemas operativos y mainframes hoy vuelve a estar de moda por los procesadores de múltiples núcleos, sí ha avanzado pero los principios son los mismos que hace 40 años. Otro ejemplo, NoSQL, las mismas técnicas de los años 70 pero usadas para tener bases de datos distribuidas mucho más limitadas que las relacionales, ¿hace falta tener una asignatura para saber cómo funcionan los hashes y su almacenamiento en fichero que viste en estructuras de datos o “algoritmia” (signifique lo que signifique)?.

¿Realmente hacen falta asignaturas obligatorias específicas sólo para “desarrollo de apps” cuando hoy lo más raro que te encuentras es que tienes que tener un thread para conectarte a un servidor o mostrar imágenes o listados largos? (ojo, sí que deben ser parte de prácticas o laboratorios, que ya se hacen en la mayoría de universidades).

¿Por qué no usaste el framework X?

Qué pesadilla, no hace falta seguir, ¿no?

Ninguno de los frameworks se ajusta a lo que necesitamos, vamos a desarrollar uno mejor

:roll: :roll: :roll:

La pasta, y la informática

Es curioso como eventos de nuestra infancia marcan a fuego nuestra personalidad futura. No siempre es así, por supuesto, pero sí hay algunos que con el tiempo parecen más relevantes que otros. En mi apunte Defiende lo que te ha dado tanto, expliqué ese mes de diciembre de 1989 que marcó mi obsesión por Internet (siempre había una excusa para poner Internet en todo lo que hacía, mi tesis doctoral, el ISP del que fui co-fundador en 1995 -todo con GNU/Linux-, los proyectos en los que participé…). Pero eso fue después de los 20 años, sin embargo hay otros de mi infancia que me marcaron aún más.

Seguir leyendo

Algunos libros para informáticos

Hace unas semanas un lector de mi blog me pidió que le recomendara unos pocos libros, aquellos que yo consideraba que eran “imprescindible” o que más me influyeron. Aunque el tema es complicado, esta mañana me puse a pensar cuáles recomendaría hoy mismo –quizás en unos pocos meses la lista sería muy distinta–.

He seleccionado doce libros, agrupados en diez temas, que considero son los que creo que más me afectaron a mi actividad profesional actual, o quizás debería decir a “cómo pienso hoy sobre mi profesión”. Podría haber puestos unos cuantos más (de Carl Sagan, o de Schneier por ejemplo), pero no podía hacer la lista tan larga ni salirme demasiado del tema: “libros importantes para informáticos”.

  1. The C Programming Language (o la madre de los libros de lenguajes de programación) de Brian W. Kernighan y Dennis Ritchie. Considero que todo aquel que pretenda llamarse programador o informático debería dominar el lenguaje C. No sólo es un lenguaje sencillo, padre de muchos otros lenguajes (¿o de dónde vienen todas esas “llaves”?) y base de muchos sistemas operativos, sino que tiene un balance muy adecuado entre “abstracción” y proximidad con la arquitectura. Pero en realidad creo que lo más importante es que este libro quizás sea el mejor libro/manual jamás escrito sobre un lenguaje de programación. Debería estar en la mochila de un programador, al menos hasta que te lo sepas de memoria, en ese momento lo podrás dejar en tu biblioteca y volver a leerlo de vez en cuando.
  2. The Mythical Man Month and Other Essays on Software Engineering de Frederick P. Brooks. ¿Crees que la nueva supe-mega-chachi metodología de software o lenguaje de programación solucionará todos los problemas? ¿te aburren mucho cuando te dan clases de ingeniería del software? Este libro se ha convertido en un clásico de la ingeniería del software, unos de los pocos que aguantan el paso del tiempo y que a pesar de la edad de la mayoría de los artículos (25 años) cada día demuestra su actualidad. Para mí este libro es a la ingeniería del software como el anterior a los lenguajes: las buenas ideas pueden explicarse de forma breve y mejoran con el paso del tiempo, como los buenos bourbons.
  3. Hackers and Painters de Paul Graham. ¿Crees que la informática es aburrida? ¿que sólo se trata de programar sistemas de facturación? ¿que necesitamos colegios y regulaciones?. El libro aporta una visión distinta de los programadores, quizás a muchos les parezca demasiado romántica, utópica o exagerada. A mí me sirvió de inspiración, o quizás para reafirmar y luchar por mis ideas “románticas” de lo que debería ser nuestra profesión. Estoy convencido que los “genios” de nuestro campo comparten el mismo romanticismo y “utopías”. No todos somos genios –por definición estadística–, pero ayudará a comprender mejor a esas personas que solemos admirar, y de paso te dará una inyección necesaria de idealismo y pasión por la informática. Efecto colateral: aprenderás a apreciar mejor a los “clásicos”.
  4. Cryptonomicon de Neal Stephenson. Una novela muy ciberpunk, divertida e imprescindible si te interesa un poco de esa “cultura” –debería :-) –. En su versión original en inglés tiene casi 1000 páginas –pero la devoré en un fin de semana–. Lo tradujo al castellano PJorge y salió en tres tomos. Creo que hace poco tiempo lanzaron una nueva edición de un sólo tomo. Es difícil explicar este libro, sólo puedo decir que me abrió los ojos para entender la criptografía desde otro punto de vista y aumentar aún más mi admiración por Alan Turing y los matemáticos que han fundado la informática moderna (y de paso han ayudado a ganar la guerra contra los nazis).
  5. Programming the Universe: A Quantum Computer Scientist Takes on the Cosmos de Seth Lloyd. Comenté algo de este libro hace poco. Si crees que está todo hecho en informática, o no entiendes muy bien qué es eso de la “informática cuántica”, o te parece que la teoría de la información de Shannon es algo muy oscuro que no te interesa, éste es tu libro.
  6. Free Culture de Lawrence Lessig. Dudaba entre éste y The Code is the Law. A los informáticos nos enseñan muy poco de historia, leyes y su relación con la informática. Ni siquiera sabemos interpretar una licencia de software. A pesar de ellos nos encanta poner “copyright” a nuestros programas y hablar de la “importancia” y los “beneficios” de la “propiedad intelectual”. Estos dos libros te explicarán un poco de esos temas, desde una visión que no es la que lees en El País (ni en la web del Ministerio de Cultura), ni las que suelen explicar los profesores de informática, historia o derecho. Tus viejas ideas sobre la “propiedad intelectual” no volverán a ser las mismas.
  7. The Laws of the Web: Patterns in the Ecology of Information de Bernardo A. Huberman. Linked: How Everything Is Connected to Everything Else and What It Means for Business, Science, and Everyday Life de Albert-László Barabási. ¿Cansado de oir tanto de “redes sociales”, web 2.0, que Facebook es la nueva revolución o de las “largas colas”? ¿Crees que las “redes sociales” la inventó O’Reilly mientras miraba un partido de beisbol? Pues no. Estos dos libros te darán una explicación introductoria y fácil de leer, pero a la vez rigurosa y científica sobre esos temas, su utilidad en diversas áreas y cómo se están usando para aplicaciones “sociales” menos frívolas que el Poke o SuperWall. Además darán bastantes pistas de porqué algunos afirman que la informática está “migrando” de intentar obtener resultados “precisos” con pocos datos a obtener resultados “aproximados” a partir del tratamiento de “datos masivos”.
  8. UNIX Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers de Curt Schimmel. Es un libro muy técnico, muy hardcore, pero no es sólo útil para programadores de núcleos de sistemas operativos o para Unix. Sirve para cualquier programador que desee conocer mejor los problemas de concurrencia y multiprogramación en cualquier sistema informático, cómo se interactúa con el hardware para aumenter la eficiencia y evitar los errores de concurrencia o los nuevos métodos más eficientes de control de concurencia. Si no entiendes nada de lo que cuenta este libro deberías replantearte seriamente si te consideras un “informático”. O mejor aún, estudia hasta que logres comprender al menos superficialmente lo que cuente el autor, tu calidad como “informático” habrá ganado muchos puntos.
  9. The Structure of Scientific Revolutions de Thomas S. Kuhn. Alguien que sepa de filosofía podría discutir sobre muchas de las hipótesis de Kuhn. Otros dirán que Popper aporta una visión más moderna y cercana a la realidad de la comunidad científica. Podría ser, pero lo importante de este macroensayo es que nos introduce de una forma apasionada a la historia y filosofía de la ciencia, un campo en el que no solemos distinguirnos los informáticos. Como no podía ser de otra manera, existen fuertes paralelismos entre la cortísima historía de la “ciencia informática” y la un poco más larga “ciencia moderna”. Este libro te pondrá en perspectiva y te dará otra visión más escéptica de lo que dicen los gurús de moda.
  10. Software libre para una sociedad libre de Richard Stallman. También en catalán: Programari lliure, societat lliure (Benjamí y yo hemos supervisado la traducción a pedido de Stallman). Podrás no estar de acuerdo con todas sus ideas, pero la lógica implacable de este “visionario” no te dejará indiferente, pondrá en crisis muchas de las ideas y preconceptos que tenías. Como bien dice Lessig en el prólogo: Cada generación tiene su filósofo: un escritor o un artista que plasma la imaginación de una época. A veces estos filósofos son reconocidos como tales, pero a menudo pasan generaciones antes de que se caiga en la cuenta. Sin embargo, con reconocimiento o sin él, cada época queda marcada por la gente que expresa sus ideales, sea en el susurro de un poema o en el fragor de un movimiento político… Nuestra generación tiene un filósofo. No es un artista, tampoco un escritor profesional. Es un programador.