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.

There’s no such thing as a good developer

Well, not exactly (though if you read this you might get pretty convinced of that). I already tried to make my point about this problem in a previous article, where my main argument was that a programmer always needs to keep in mind whomever is gonna use his code in the future, and write against the level of knowledge of that people. I said there that experienced developers should be able to “step down” from their knowledge sometimes to write code that is easily understandable to their less experienced colleagues. This has a lot to do with legibility, simplicity, maintainability and documentation, but other subjectivities like great communication skills, an iron-forged patience and not being a jerk (because no one wants to collaborate with a jerk) are pretty much at game. We as developers need to keep those around us in mind as much as we can, but our advanced fellows more than anyone, because experienced people often rely on their past, their knowledge and their popularity more than they should. Here’s a harsh truth: the only fact that you have a lot of years working in your area, or that you are proficient in a lot of languages, coding practices and design patterns, or that you’re a popular and cool figure in your community, all of that doesn’t make you an authority per se, all of that doesn’t make you right all the time. As well as technologies and practices evolve quickly, so does the context you’re working in. Nobody is that cool or wise while not working constantly to improve what he’s doing. Not even myself, so don’t believe me just because I’m saying this -you can take a look at my code online and see how there are both good and awful things, all belonging to different periods and contexts of my work- just go see the work of some so called seasoned developers and see for yourself who you think is really good and who just relies on his name. See how much of their code you can understand by giving it a simple read. There are a lot of developers praising their own code, but not everyone can be understood first-hand.

But there are some good WordPress developers

I really like the fact that in the WordPress community we don’t have a lot of developers just praising their experience. Yeah, we have some, and a couple of them are, in fact, very popular, but they don’t change the big picture. I like to think of most of the people in the community as people of action. We have a lot of folks concerned about good programming practices and building efficient and very readable coding standards. But it seems to me that some of us sometimes try to find the one and only correct way to do things. I know that happens to a lot of programmers, and probably in other communities too. But having worked on a lot of projects, both related to WordPress and other platforms, I agree with Tom: I really don’t think there’s a unique way (or a unique set of rules) to do things the right way, even in different projects based on the same language or framework. One of our problems is that, sometimes, as almost every developer in some point of his/her career, we tend to overdesign or overcomplicate things for the sake of completeness. We apply OOP and complicated classes when we don’t really need to do it, for projects that can simply be done using functions and procedural or structured programming, or viceversa. We tend to marry some practices, and our main reason to do it is that we really like them and feel comfortable using them, even if we don’t always need them. We tend to consider some of our practices as the best that can be applied ever, and keep forgetting our context and the people around us. For example, Tom wrote in his second article about a conversation he had with Thomas Scholz. Following that conversation, one of the things that drew my attention was an affirmation about nesting function calls, something that supposedly complicates things instead of simplifying them. Well, I don’t quite think so. I think you need to keep in mind the people involved. If you work with people that feel comfortable with nesting calls, there’s no reason not to use them, but if your coworkers are not familiar to them or find them hard to read, then you shouldn’t. Just as simple as that. There’s no quick guide to readability, as there’s no quick guide to readers.

But sometimes our colleagues are the entire world

Of course up to this point the majority of my points can be applied only to code that is not meant to be distributed. You may know your close fellow programmers and their level of knowledge and experience, but you can’t know the same about all the people that may be using your code out there if you’re gonna put it in the Plugin Repository or Github. That doesn’t mean you should write carelessly because your code can get to all kind of programmers – most quite the opposite. You should be even more careful, because you can’t afford to change things all the time just because different developers with different preferences find some part of your code hard to read. There won’t be a precise actual public for your code, but there can be a hypothetical one. The best you can do here is to speculate with a certain kind of public that your code is directed to. You can think of it as an imaginary model programmer with certain abilities, experience and preferences, something similar to those personas built in marketing to target client profiles. Your model should feel comfortable with some coding practices, and not so much with others, just as any programmer would do, but you should keep it realistic. Maybe you can base it around yourself or a fellow developer. Then you can write your code at your own preferences, as much simple or complex you consider it needs to be to fulfill the demands of your model. Obviously, you need to follow some standards for guidelines, documenting and commenting, because you can’t rely on your code being readable for everyone, no matter how much measures you take. Of course you can always try to keep it readable and accessible for people with little knowledge of programming. That’s the “official” approach of WordPress, as you can easily see in most of core files, so we can assume it’s the best of approaches. But you can’t always afford it. When you learn new coding practices and possibilities, become familiar to them, and apply them in your daily work, your mindset changes, making it hard to even think on how to resolve certain things again the way you did before. That requires time and effort, and you won’t always have time or energy. Sometimes it’s more practical to put yourself a floor and a ceiling, saying to yourself something like “I won’t go below this complexity, but neither further than this other”. How to measure that levels of complexity is only up to you.

Ain’t nobody got time for that

Of course you won’t always be able to afford investing your time in writing your code to fill your ideals, but that doesn’t mean, under any concept, that you should consciously write bad code just because you don’t have the time to do it well. There will be times when you need things working as soon as possible, when your boss or your client can’t or don’t care to pay for good quality as long as the software just works, or when a project can’t be delayed any longer. You can try to talk it down and reduce the scope of the project, argumenting on higher maintainability costs for projects fastly developed and poorly coded, making them know that good quality takes time, and that there’s not such a thing as a super fast genius programmer, because sometimes you just have to spend eight hours in four lines of code, and that’s OK, is what happens to all of us, and probably more than we’d like to admit. It’s not that we’re lazy, is just how things work here, and people that are not programmers need to learn to deal with that if they want software that lasts. And if they are inflexible, or you don’t want to have this kind of talk because you already know you’re gonna lose it, ask yourself if you really want to do that job. And yes, I know you may think you can’t afford writing good code, because you have to pay the bills somehow, but can you afford not growing?

tl;dr

So basically, the points I’m trying to make here are just a few:

• You cannot rely on a specific rule of thumb to write your code to make it accesible, because accesibility depends on the context and the people involved. A good programmer should learn to adapt to his/her environment.
• Getting things to work isn’t (or at least it shouldn’t be) the opposite to write quality code. That’s an excuse, sometimes unconscious, for not doing things better.
• Your code will always be far from perfect, no matter how good you are, so please stop praising your practices and trying to force people to adopt them, because what serves to your own purposes may not serve others’ as well.
• Don’t just talk about how good you are. Show it, and always keep learning, no matter how much experience you have or how cool people (or yourself) think you are.
• Most important, don’t talk about how bad other people code. Try not to laugh at the code you don’t like. I know it’s fun and we all have a good laugh sometimes with some piece of crappy code, but we’ve all been there too. We didn’t born knowing how to code, we all wrote some messy horrible things in the past, and maybe we keep doing it from time to time without even realize it. Instead, try to educate, offer help for people to make it better, because I’m sure you find yourself in need of some kind of help more often than not.