I review a lot of code. A lot.
On average, I look at around 100 plugins and themes (combined) per day. If I’m not reviewing code for the WPORG plugin repository, I’m debugging sites for customers, writing my own code to make it better, testing patches for WordPress, and pretty much dancing the dance a lot. I like this sort of thing a lot, since I get to see all sorts of different methods to madness, and it improves my abilities to see people doing it right and wrong.
That said, I’m not the best coder in the universe. I don’t claim to be, I don’t plan to be, and I don’t worry that I’m not. We all have our skills and mine is not to be a psycho awesome super coder. Mine is debugging, breaking, helping people debug and break, and writing. We call that support, generally, and it’s a noble profession! But more on that another day. The fact is I don’t know all the code in WordPress. I’m guilty of
doing_it_wrong() often enough. And yet, I don’t see my ignorance to be a detriment to what I do.
In an article “Probability and Possibilities”, my father talks about how we react to natural disasters, and how that impacts how we predict them, and their costs. Near the end, he talks about being prepared by having resilient responses, and lists the following traits of those people/groups:
- Drawing on experience
- Questioning that experience
- Improvisation, or making the most of materials at hand
- Listening and speaking
- Examining preconceptions
- Ignorance + knowledge = wisdom
- Recognizing and taking advantage of luck
I didn’t realize it at the time, but my dad raised me to be resilient, because those eight traits are ones I apply constantly to my code reviews. It’s because of those that I’m able to do all those plugin reviews, even when I don’t know all the right moves. As a senator once said, I know it when I see it.
Many times, I’ll review a plugin and flag it saying “This is not secure” or “This is not done properly” and sometimes I’ll take a moment to explain exactly why, but given the sheer volume of reviews I need to get through to keep up my end of the review process I will often use some standard ‘predefined’ replies. I don’t review all plugins, nor do I reply to all the emails, though sometimes I know it looks like I do. Still, if one person has to review 25 plugins a day, and craft a reply for half of them (yes, about half the plugins we get need some sort of reply that isn’t ‘approved!’), how am I, a non-uber coder, capable of actually knowing that the code is wrong?
I’m going to tell you the biggest secret of support ever. You ready?
You don’t have to know how to fix what’s wrong to know that it is, in fact, wrong.
That’s it. Not knowing how to fix things was, I admit, one of the leading causes as to the impostor syndrome feelings I had when writing my WordPress Plugin Support ebook. But the thing was, I knew that the code was right or wrong most of the time. Oh, sure, I make a couple mistakes, but if I see someone calling
wp-load.php directly in their code, I’ll tell them it’s not permitted and then they get a canned reply as to why, with some general suggestions.
I stopped worrying about not being able to help someone debug their own plugin for a couple reasons, though. It’s (generally) not my job to help you write your own code. If you have a jquery conflict or need help calling WP functions outside of WP (please don’t), I can help you with a search or suggestions where to ask, but just because I don’t know the answer doesn’t make my telling you that you’re not permitted to do something in the WPORG repository invalid.
Ah, there’s the crux isn’t it? Someone was doing code in a totally janky way. It happens. Most of the time, we end up doing this by accident, not knowing there’s already a WP function or action to use for it. We reinvent the wheel by accident. Let’s pretend this guy was using his own copy of jQuery. Now, as we all know, you don’t need to do that! WordPress comes with jQuery and you can just enqueue it. So there’s a canned email we send, explaining you can’t include your own, nor can you call it remotely, please use ours.
The reply comes back “My code won’t work without my own.”
So I reply to the effect of “Please correct your code to work with our version of jQuery. The most common cause of these conflicts is not writing your code to work in no-conflict mode.” And then there was a series of links.
He replied, “Why don’t you just tell me what I did wrong?”
I explained I would if I could. But I don’t know his code, I’m not awesome at jQuery, I don’t care to reverse engineer everything to figure out exactly what’s broken, and it’s not my plugin anyway. So … no. I don’t know how to fix it, but I do know that, having listened to a lot of smart people and having read a lot of code, that the primary cause is an issue with no-conflict mode. So I can Google that and get wp_enqueue_script() – jQuery noConflict Wrappers as a hit (this is the WordPress Codex) and read that this happens if you use the
$ shortcut, so I take a second look at his code, determine this is the case (though perhaps not the cause of all issues), and reply back with that info and a link. I’m helpful.
He doesn’t agree. “If you know so much, you should fix it.”
No, sorry. This time I explain I don’t know much more than that as I’m not great with JS yet, and now I expect to get smarmy commentary on how, if I don’t know how to fix it, I don’t have the right to tell him it’s wrong. After all, I’ve heard that a hundred times before. Instead, this guy says “Yeah, I don’t know either, so who am I to judge? Okay, any suggestions where to ask for help?” After picking my jaw off the floor, I sent him to wp-hackers and stack-exchange, after doing a quick search to see what other direct links might help, including one on SE that looked like the absolute answer. He came back, said the SE answer was it, and everyone was happy!
I solved the issue by being resilient, and giving the ultimate support. Also now the guy has the tools to do it himself next time.