Hace algunos días vi The Martian. Si no la viste, lo deberías hacer ahora mismo, y si no querés ningún spoiler sería bueno que dejaras de leer en este momento.
El problema de la autovalidación
A veces los programadores tendemos a pensar que nuestra manera de resolver problemas es la mejor posible. La autovalidación en sí misma no es mala, pero cuando se convierte en vicio está lejos de ser realista. Basta con buscar un poco de información en internet acerca de algún problema que estemos intentando resolver, y nos vamos a encontrar con un montón de propuestas diferentes, a veces hasta contradictorias, y unas cuantas discusiones acerca de por qué ciertas soluciones son perfectas y las demás son producto de los pensamientos de una mente idiota. Nuestra propia solución probablemente no esté fuera del cuestionamiento de los críticos. De hecho, hasta podemos estar increíblemente errados.
Programar no es (tan) complicado
Aprender a programar no es exactamente fácil, pero tampoco es lo más difícil del mundo. La dificultad no tiene tanto que ver con entender la sintaxis de un lenguaje, o los conceptos básicos de la programación en general, sino con aprender a manejar distintos problemas que van a ser encontrados de forma inevitable mientras escribamos código. La sintaxis y los conceptos básicos son cosas muy sencillas y que resultan incluso muy intuitivas, porque en general tienen que ver con la vida cotidiana de cualquier persona que haya aprendido a leer y escribir, sin importar demasiado qué tan bien lea o escriba.
Martes 26 de Agosto: Nueva Meetup en Buenos Aires
En el marco de esto que se viene tratando de armar hace ya casi un año y medio, es decir una comunidad dedicada a WordPress en Argentina, y después de las dos exitosas Meetups por el festejo de los diez y once años de la plataforma, finalmente vamos a estar presentando nuestro primer evento semi-formal, a manera de introducción y presentación a un público general a lo que estamos tratando de hacer.
El evento va a constar de dos charlas introductorias y correlativas. La primera, a cargo de Juanfra Aldasoro, coworker de quien escribe y fundador de NiceThemes, va a consistir en un repaso por la historia de WordPress, viendo de qué manera llegó a convertirse en la herramienta con la que están construídos alrededor del 20% de los sitios web, y la importancia de cosas como el open source, GPL y la comunidad para que esto sucediera.
La segunda charla va a ser dictada por mí, y vamos a hablar de las distintas cosas que se pueden lograr con WordPress, cómo extender y saber separar funcionalidad y presentación, y de qué manera construir un entorno de desarrollo profesional que nos permita trabajar de la manera más rápida y eficiente posible, sin importar si uno se dedica a diseño, programación, maquetado, blogging o management.
La cita es el día martes 26 de agosto, a partir de las 19.30 hs. en Areatres Labs. La entrada es gratuita y al finalizar las charlas vamos a continuar con el encuentro de manera totalmente informal en medio de pizzas y cervezas.
El RSVP al evento se puede hacer acá. Nos vemos ahí 🙂
More Thoughts on Writing Accessible Code
Recently, two articles from Tom McFarlin drew my attention. In fact, it was two months ago, like years in internet time, but I think the matter is still relevant, despite the fact that this post has been sleeping in my Evernote account much longer than I would have liked. The first article (Simplifying Code in WordPress: Option Arrays) was an attempt to address different ways of checking the availability of array keys in WordPress Options API. There Tom offered a couple of methods to do so, and that led to a discussion in the comments area about one-line solutions, platform compatibility, readability, and simplicity versus complexity.
The second article (Don’t Just Get It Working), published one day after the first, was more of a reflection on how we, as developers, sometimes tend to try (or not at all) to have our software built in a somewhat ideal way, being not enough for us to just have it working and doing what it’s supposed to do. We know how it goes from here: that way we can build products with higher quality and maintainability, but also take the risk of becoming so perfectionist that our projects end up being delayed because we can’t decide if braces should be put before or after a new line (for me it’s always before, BTW). There are also those who don’t care too much about what they write and just want to have things working as soon as possible just to make it home, watch Wilfred and bathe in cynicism and depression. There’s no blame nor shame in that, because programming sometimes can destroy all the purity of your soul, though I think we can make the life of that kind of people a lot easier. And there’s another group of people, those who used to write good code, but got so lazy and confident of their own work that ended up writing pieces and pieces of real ape-bull-boar crap while thinking of it as an epiphany. Such a paradox, uh?
This last group is the one that interests me the most. I think it’s easy to see how, once we gain experience, sometimes we write complex code for the sake of brevity or performance, but forget to make it accessible for other people that could eventually work with it. That often leads to code that is only easy to understand by its own author, but over time the author himself may find it hard to read. I think we don’t give enough attention to this fact.