13 Ways to Annoy a WordPress Developer

Having worked for more than 10 years as a web developer, and many of those years specifically with WordPress, I’ve seen (and written) a lot of terrible code… and have accumulated a number of pet peeves along the way.

So today, I thought it would be interesting to share and perhaps get a discussion going about the things we, as a WordPress community, don’t like.

So let’s count down the 13 things that annoy me the most, in no particular order…

1. Inconsistency

I lied, there is a particular order, sort of. I’m starting with what annoys me most, the rest really is in random order, honest!

Inconsistency is the worst enemy you can have as a programmer, when you work with systems and data structures.

Did you mess up all your function prefixes? Did you save a meta value 1,000 times with an incorrect key? Absolutely no problem, just search and replace. Do you sometimes mess up the prefix, but sometimes remember the correct one? You may need to go through the whole code, line by line.

Something done incorrectly but consistently incorrectly is far better than something done right most of the time.

Don’t forget to apply this rule when you’re extending someone else’s work. If they’ve used camel case – which you hate – it may be worth sucking it up and conforming because that’s what other developers will expect.

2. Bloated Products

I really dislike the fact that some “multipurpose” themes come as a 100MB+ download, even though the actual files that run the theme are under a couple of megabytes. There is no way a Jack of all trades theme will be better than a well-made niche theme.

I understand that the driving force behind this is demand, which is why it is so difficult to change things. It’s all well and good to stand against bloated themes, but they have a much higher earning potential so naturally businesses will make them.

I’m hoping that just like Jason Schuller’s Pickle Theme many authors will come along with focussed themes that add more to a website than just a barrage of eye candy that turns out to be useless when you look at the stats.

3. Hordes of CSS and JavaScript Files

This one is one of my biggest pet peeves, especially if you’re a theme maker, and even more so if you make premium themes with sliders and all the other junk that seems to be the norm now. You simply can’t let 45 Javascript and 18 CSS files load for each request, it’s just plain wrong!

The counter-argument is usually that this makes it easier for developers to make changes. There is, of course, a solution to everything: use Sass/Less and build tools like Gulp. Create a developer directory which contains all the raw Sass and JS files and use a Gulp or Grunt to put everything together into a couple of files. Since the information about the build process is contained within the project, anyone can take over any time.

4. Unprepared Parent Themes

If you’re releasing your theme to the world, chances are someone somewhere will want to modify your work. Whenever this happens we scream bloody murder if a child theme isn’t used, so we should make some effort toward supporting them in our work, especially in the functions.php file.

If you’re creating a function that acts like a template tag, wrap in a function_exists() call to make sure child themes can override it properly. Child theme functions are loaded first so if they try to redefine our work PHP will spit out a “can’t define a function twice” error.

5. Incomplete Documentation

To be honest, I’m more ticked off when I read incomplete documentation than I am when it is missing completely. I mean, why do 80% of the work and not push through the remaining 20%?

If you decide to share your project with others, do document it! Especially if it’s code that is meant to be reused, overridden or otherwise changed – this happens all the time with themes and plugins.

If you want to go all the way, I recommend separate documentation for developers and end users. End users just need to work with the UI, while developers need to find things in the code, know versions of various components and all sorts of other information.

6. Going Overboard With Prefixing

I know that you have to prefix your functions, but please don’t use 23duasn123uehd_ as the prefix. I understand that this has 0 chance of colliding, but surely if you’re developing a mailing list plugin you could prefix your functions with awesome_mailing_.

If you really want to set your functions apart then forget about prefixing altogether and use classes and objects to encapsulate them – problem solved.

7. Not Enqueueing Properly

It should be a given that if you need some CSS or JavaScript you enqueue it, so I’m not even going to say anything about that. In addition, do take some care to enqueue assets only when they are needed. Do you really need to load the styles and scripts for sliders on all pages? Of course not, only load them when a slider is actually displayed.

Also, try and use HTTPS where possible, or better yet, use //sourceoffile.com/file.js. Just leave off the protocol and your browser will figure it out for you. Awesome!

8. Misdefining Web Development

This might come across as a bit crass, but if you buy a theme, tweak and tune the settings, teach a client how to use it and wrap up a project, don’t call yourself a web developer.

Before you start throwing rocks at me, there is absolutely nothing wrong with doing this for clients, it’s how many developers, myself included, started out. However, calling it web development is stretching it a bit far.

9. Hardcoding Things That Should Not Be Hardcoded

A great many things fall into this category. One prominent example is the use of the wp_ database prefix in queries. The database prefix can be changed in an installation, so you should use the $wpdb->tablename property instead.

You should never hard code plugin and theme locations since these can also be changed. Whenever you want to hard code a path, just search for “WordPress X path” and substitute X for whatever path you’re looking for. If the location is variable you’ll find a function to get to it without hardcoding.

10. Non-Translation Ready Themes

I’ve been lucky enough to grow up with English since I was two-years-old, so in a large part of the world I am understood easily enough, and software is written in a language I understand very well.

Have you ever travelled abroad and wished you were able to read something? Imagine that feeling all the time on the web, the place you go for information, and feeling confusion and uncertainty.

Translations are becoming a huge part of the WordPress community and since it takes almost no effort to make this happen in your products, you really don’t have an excuse not to implement it. You’ll be using all of two functions and wrapping __() and _e() around your text is not that hard. Really.

11. Narrow Mindedness

This is actually my biggest annoyance of all in general, not just in the development world. With developers, you see this often when talking about Joomla/Drupal/WordPress, or even more so if you talk to Java developers about WordPress.

Many of them look down on WordPress developers since WordPress is not a perfect system; it isn’t the epitome of modern code, for sure. These developers are simply missing the point. WordPress is a tool that fits a certain task very well. It doesn’t fit all tasks, nor is it intended to.

People very often fail to take into account that there are other considerations than their own point of view and there may be more important ones at that. A good example is the developer who wants to rewrite WordPress to make it all nice and object oriented. Sure, as a developer I’d be extremely happy with that, but we would be breaking backwards compatibility. We would cause issues for literally millions of people for the benefit of a couple of thousand stubborn developers.

As a rule of thumb, if someone has extremely strong and aggressive opinions about something, I dismiss them right away as not being able to see all points of view. There are, of course, exceptions, but it has been a good indicator for me.

12. #wpdrama

Really? Don’t we have better things to do? To be honest, I have never read through more than two comments in any given #wpdrama situation because I just don’t care. Obviously, I care about the issue behind the drama, but by comment number three it devolves into a free-for-all that’s not really about the issue at hand but about who is biassed, who isn’t, who has more experience, who is a more professional developer… blah, blah, blah. Yawn, I have better things to do.

That said, I love intense debates. Different opinions are healthy and provide different points of view, particularly as this often drives many great WordPress features. Drama, on the other hand, decreases productivity across the board. Gross.

Bonus: Rude/Weird Emails

This isn’t development-related, but I have three specific type of emails I really dislike or at least find funny. Way at the top of the list is the type of person who has read that mentioning someone’s name in a conversation multiple times shows interest, increased connection and sympathy. Nope, it makes it all super-weird.

This same type of person usually also calls me “Dan.” Apart from that one sentence just now I have never-ever written my name like that. If you see someone’s name on a website, do use their full name; if they tend to use a shorter version I bet they’ll sign their initial response with it. Also, just use a name once, maybe twice, otherwise it’s creepy. Or is that just me?

Type number two is the super short email that literally goes: “I want to learn WordPress and need your help in this regards. Thanking you..” (that was an actual email I received).

There is also number three, the super-long variant of asking for help, which actually doesn’t have a question at the end. The sender goes on and on about what he’s doing and what problems he’s having and then just signs his name.

So What’s Your Pet Peeve?

Have any of my annoyances hit a nerve with you? Surely you have one (or a few) of your own pet peeves.

Let us know about the things that annoy you most about working as a WordPress developer, and if you’ve ever received any rude/weird emails, share those too!

15 Responses

  • Design Lord, Child of Thor

    It’s not just you, Daniel. When someone mentions my name more than ones in a conversation or email, it just kind of creeps me out, Daniel. It’s like when the stranger or near stranger mansplaining something to you decides you’ll understand better and be able to concentrate more effectively if he touches you more. Especially on your ass. >.>;;

    And, since you asked… My pet peeves. (Warning – I lack your restraint, and intend to have fun railing at these things without much in the way of filters – which, unfortunately, is probably someone else’s pet peeve. :)

    My pet peeve – especially in WordPressLand, but also in Corel, Adobe, 3D software, etc. (and now you know I’m a designer much more than a developer, right? ;-) starts off like “Why would you add these seventeen functions, but then not add this incredibly simple and obvious one?” but, is really, probably, more accurately depicted as “Why didn’t you add all the features -I- would want, and leave out all these useless features someone else would want?” :)

    Like – Maybe “normal” people don’t get cheesed off at this, but am I the only person who knows how incredibly easy it’d be to re-color all interface elements in an OS, and is infuriated by how Microsoft has decided most of my Win10 interface should be blindingly-pale-gray, or that Google has decided that my whole interface should be this nightmare cacophony of — I mean — where did they get these colors for Lollipop? Crayon & marker colors rejected because they tended to incite even 4 year olds to homicide?

    At this stage in the game, how is it even fathomably acceptable for any element of the user interface for a phone or computer to not be subject to complete, unbridled, simple, easy color, size, and layout customization

    Oh, and flat and/or minimalist “design”. Omfg, how I hate flat design. And minimalist design -isn’t-. It’s that freekin’ simple. It. Is. Not. Design. It’s the emperor’s new clothes for your eyes. It’s some $#[email protected]! who’s been saddled with a self-induced cranio-rectal occlusion for so long they’ve suffered hypoxia of their Taste & Style lobe, and now they’re sniffing snootily while saying “Yes, the whole interface is just a vertical black bar with a single black box above it. It’s meant to evoke the sense of a lowercase letter i – because the site is entirely about the viewer, but one viewer isn’t any more important than another.”

    You just want to slap them and say “Shut up, go to the cafeteria, and cook me a drop shadow, you vapid, horrifying waste of a liberal arts degree.” No matter how much it appeals to your tragically chic sense of artistic irony, not designing is not design.

    What else… Yams. Don’t like yams. Not one bit. You guys, though – You, I like. ;)

  • New Recruit

    Regarding point 2 it really depends on the Theme developers knowledge about front-end features that webdesigners look for to deliver a professional website that meets the demands of the customer and also provide a good visitor/user experience.

    Some developers create Themes with complex admin panels from a ‘look at me and see what i created’ standpoint, but others create intuitive admin panels which are developed from a front-end perspective with the website visitor in mind. There a few commercial Themes that actually let’s you create those ‘Pickle’ approach websites using their full-bloated Theme.

    Point 7: I really hate when this is not properly coded and you are left with 15 CSS/JS files that load on pages where the actual functionality of a plugin is not used.

    Point 8: I agree. I am a Web Builder and thank all Web Developers that make it possible for me to build websites.

  • New Recruit

    In the theme development business don’t say you support WooCommerce and then manhandle all the WooCommerce templates so badly that upgrades to newer versions of WooCommerce become almost impossible without personally having to inspect EVERY bundled template page, and adding your own highly customized functions that render the upgrade nearly impossible without having to tear every page out of theme and cross check all your completely undocumented theme options, and please don’t introduce things like Isotope to product pages without a way to turn them off.

    Now try explaining to the client that they can not upgrade because the theme a designer chose is completely incompatible, and it will take a complete rewrite of the the theme to fix the problems that the theme developers introduced when they made a claim of WooCommerce support in the first place. Makes that $45 dollar choice seem like a $1000 mistake, and the client doesn’t want to pay the bill.

    Anyone who claims to be a theme developer should either learn how to use filters, actions and supplemental functions, or punt on claiming support for other coding extensions. Just shoving every WooCommerce template into a theme folder, and adding your own functions to the template is NOT supporting WooCommerce, it’s a poor excuse for being a no-talent hack who doesn’t understand how to support a community of developers.

    Thank for letting me vent that one. I just fired the last ‘designer’ who made it a developer’s problem to once again fix their poor theme chooses and made me eat the coding time to fix his mistake.

    I’ve had it with theme developers dumping their craptastic products into market and then leaving it up to developers to sort out their mess at our expense.

  • Flash Drive

    I’m sad to say I’m guilty of 1 & 9 and a few others (but not the Bonus name thing…that is creepy). But I’m a work in progress and getting better. For better or worse I don’t sell my themes or sites. I use them to provide services. So I’m the developer I’m most annoyed with. That awful inconsistent code that I thought was brilliant 2 years ago is mine!

    I pretty regularly rewrite things that at the time were “to the best of my ability” and I often am grateful I’m the only one who peeks under the hood. I suspect the things I fix today I’ll be appalled at when I look at them next year.

  • WPMU DEV Initiate

    I think you’re over-complicating #1. Yes, if it should be A and I write B, a find & replace will take care of it. If I sometimes write A and sometimes write B, the same find & replace will work too. Which I suppose makes it even more annoying, since it would take so little effort to correct before dumping it in your lap.

    I agree with Joe about the long email sigs, especially in forums/discussion lists. A 2 line comment with a 17 line sig is the worst I’ve seen so far.

  • WPMU DEV Initiate

    OMFG I literally laughed so hard at this that I started to choke just a little. Could not have said it better had I tried. I rail against this crap at every opportunity, and my other half despises it so much that years ago when I unintentionally screwed up a jailbreak on her iphone that resulted in never being able to revert to iOS6 from iOS7, she refused to ever use her phone again until we went out and bought a used 4s with iOS6 on it from someone on Craigslist.

    Flat design is crap. Always has been, always will be. I’m just waiting for the rest of the world to finally admit it and move on.

    ——
    On October 15, 2015, 11:37 am, Honor said:

    Oh, and flat and/or minimalist “design”. Omfg, how I hate flat design. And minimalist design -isn’t-. It’s that freekin’ simple. It. Is. Not. Design. It’s the emperor’s new clothes for your eyes. It’s some $#[email protected]! who’s been saddled with a self-induced cranio-rectal occlusion for so long they’ve suffered hypoxia of their Taste & Style lobe, and now they’re sniffing snootily while saying “Yes, the whole interface is just a vertical black bar with a single black box above it. It’s meant to evoke the sense of a lowercase letter i – because the site is entirely about the viewer, but one viewer isn’t any more important than another.”

    You just want to slap them and say “Shut up, go to the cafeteria, and cook me a drop shadow, you vapid, horrifying waste of a liberal arts degree.” No matter how much it appeals to your tragically chic sense of artistic irony, not designing is not design.

Comments are closed.