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.
