This guide isn’t only to help clients from getting ripped off by crap developers…but also for anybody trying to decide between which themes and plugins to buy.
Maybe it’s happened to you before. You paid a lot of money to a sweet-talking developer or bought a plugin you thought was coded well. Brought it home, installed it, and it blew up in your face.
- Your next developer looks and goes…“Your last developer was a piece of crap. Whoever built that did a terrible job!”
- And this is where you go…“Oh but I don’t know how to code. I couldn’t tell!”
That buyer’s remorse can now be a thing of the past after I show you how to tell from the outside.
NOTE:
- A good developer can have all or only some of these signs. They aren’t a requirement. Just cues that I personally look for.
BASIC signs
These are easy ways to judge a developer’s quality even without knowing how to code or having to look into things that are so technical.
1. Website design & UI
Honestly. One of the easiest giveaways here. If their website looks messy or the spacing isn’t totally perfect…it’s a dead-giveaway this ain’t a professional developer. You have to know that real developers are extremely intelligent and always growing with each project.
Knowing that they never take a step back…seeing a poorly-designed website should tell you they’re still in the beginning stages of their developer career. A top level developer, even if he/she isn’t a superstar designer will still have seen enough professionally designed projects to know how things should look.
There is only one hard part about this sign. It’s that some “developers” use themes that look fancy and already spaced out nicely. So you’re not seeing a true reflection of their (personal) work. The easiest way to tell the fancy is not really their work is if you know what stock templates look like. Everything about their site screams generic. They’ll even have made-up staff names to appear bigger (or more “American”) than they really are.
There’s also another hard-to-tell part…sometimes, it’s developers who have zero sense of UI design but are still ultra-fantastic coders. In fact, they almost seem to take pride in brutalist frontends. It’s ok, we move on.
2. Documentation
(This tip is especially relevant when picking a theme or plugin.) A great developer is usually very detailed and organized. It’s not just a habit of excellence but a trait of necessity. Successful developers selling popular themes/plugins do not have time to help clients on every basic issue. So they’re forced to write thorough documentation.
If you don’t see good documentation? Probably means:
- A) they don’t have a lot of customers,
- or B) they don’t care about good support.
How is good documentation a reflection of good coding? Well good coding is largely a part of how organized and neat it is. And some developers will take shortcuts or just not care about little details. To me when I see good documentation, I know that means the developer takes pride in their work AND has had enough time to do everything correctly. Whereas a developer who is too busy to write documentation is probably too busy to code thoroughly and make changes over time.
It’s also especially nice that you see documentation for DEVELOPERS, not just for end-users!
3. Name availability
Great developers are proud of their work and want to put their name on everything that they do. If you’re trying to buy a theme and you see the head developer’s name up front and center, there’s a very good chance it’ll be respectable.
But what if you don’t see a developer’s name publicly listed on the website? Ha, that could mean anything. Could mean the developer is new and shy. (This ain’t so bad.) But the worst is if they’re using low-cost contract developers. That means it might be coded by one person one year, and then another person the follower year, and over time represents a mix of clashing visions (and most likely disorganized code).
Speaking of name availability, you should search on Google like this “Bill Johnson WordPress”…and see what comes up. Who knows you might see them asking for help on basic things in WordPress.org repo forums. Or complaints from past customers for a company they just abandoned. There’s all kinds of things you can dig up if you look carefully.
4. Company focus
Most developers and development companies tend to lean either towards A) DEVELOPMENT focus, or B) MARKETING focus. A development-focused company in my opinion will always produce the superior product. Because their time is spent innovating and building perfection. The marketing-focused company might still have quality developers…but they’re busy trying to sell, trying to copy, and more likely to release things before they’re ready.
But how can you tell? For me, just look at the public face of the company. Is it a loudmouth spokesperson with promises and hype? Or is it an opinionated developer explaining what he/she will and won’t do?
5. They use their product
Does the company use their product? Because if they built it for themselves then you know damn well, it’ll be perfect. They’ve already field-tested it in actual use everyday before it got to you.
But what if they don’t use their product? That they were inspired to build it not out of personal necessity, but in hopes of making fast money in a trendy niche? Well then you’ll know it’ll be a rushed product, and lacking the hardened experience within the niche.
The other part of choosing a development company that uses their product, is that you know it’s going to be built much more sensibly. They are users themselves and know exactly what features belong in there or not. Their product will always be more innovative in the long-run than one built by a company just trying to meet every random user request.
6. Sustainable features
Experienced developers know what is a sustainable feature or not. They want to create tools that help people. Not tools that lead people to break things and clog up support channels. They build things carefully, releasing them in a clever timeframe that doesn’t encourage mis-use.
Crap developers just don’t care. They’ll promise and build anything if they think it’ll make money. They don’t care of it breaks anything or may be difficult to support over the long run. And I guess that’s it….bad developers never think of the long-run. They want to maximize profits now on this product before they abandon it soon to jump on the next cash trend.
In theory, this sign is easy to understand. But for a non-techy person how do you judge such a thing? The best way is to look at their number of complaints. Do you see a bunch of users saying “this new/promised feature doesn’t work!”. Even worse is “this ____ feature NEVER works!”
ADVANCED signs
These are more technical ways of auditing a developer or development company’s work. You don’t have to know how to code but you should be comfortable enough digging around close to it.
7. Check error log
Go to your website’s root directory (probably /home/user/public_html or /www/html) and look for the error.log file. Now look inside it and see if your theme or plugin is spitting errors. Usually ERROR is bad, WARNING can be ok. Ideally, it doesn’t generate any of that and the output is totally clean.
8. Code organization & spacing
Open up the files inside and have a look around. You should see nice uniform spacing and descriptive labelling.
GOOD CODE EXAMPLE…from ACF plugin. Beautifully-descriptive code comments with clear formatting (big multi-line comment breaking up large globs of code), followed by a logical function name get_data that matches what it does.
/*** get_data** Returns data or null if doesn't exist.** @date 28/09/13 * @since 5.0.0** @param string $name The data name.* @return mixed*/function get_data( $name ) {return isset($this->data[ $name ]) ? $this->data[ $name ] : null; }
BAD CODE EXAMPLE…code comments that don’t explain what the function is doing. Poor formatting (no spaces) making it hard to read. The function name clearPa isn’t as obvious that it’s for clearing the page cache until you read further. Then you see other lines right beneath that don’t have any comments whatsoever. Diagnosing issues on this site would take longer just because the code is harder to read and missing helpful descriptions to explain how it works.
/* For caching */
function clearPa($post_ID) {
if (function_exists('w3tc_pgcache_flush')) { w3tc_pgcache_flush(); }
return $post_ID;
}
add_action('wp_insert_post_data', 'clearPa');
add_filter('relevanssi_get_words_query', 'fix_query');
function fix_query($query) {
$query = $query . " HAVING c > 1";
return $query;
}
In all honesty, this one isn’t that bad. I chose it as an example because it still somewhat made sense. There’s been many times when I saw so many functions that were either completely ambiguous OR they had so many functions with overly similar names.
9. GitHub activity community contributions
Not every developer and project will be publicly available on GitHub but it’s a good sign of them being with the times. For example…let’s compare 2 popular backup plugins:
- BackWPup (GitHub) – made by a much superior development company. You see lots more contributors and overall activity.
- WPvivid (GitHub) on the other hand…is crickets. A deafening silence.
Their GitHub lets you see what other projects they’re involved in, and who else they’re associated with. I love to see experienced developers contributing to a project as that means it’s a respectable one and likewise reflects nicely on them as well.
Does it mean an open project on GitHub will always get more community contributions/improvements than a privately-managed one? Ehhhh…not if the private one is a large company with dedicated full-time devs. But still, it’s nice to see.
10. What other devs are saying about the code
This is most easily seen if you’re in online dev communities that freely voices honest opinions. In some communities, it’s hard as devs are scared to (publicly) crap on another dev’s commercial work.
Another easy way is to lookup the theme/plugin’s 1-star reviews on the WP repo. Stay away from the angry noobs that don’t know how to do basic things and see if there’s any developers making factual detailed rants and unveiling poor code or shadily-hidden functions.
11. Audit the code yourself
If you know how to code, you can look at it and see many things for yourself:
- How neat it is.
- How cleverly they accomplish complex tasks.
- Whether it was written from scratch or just a hodgepodge of “borrowed” code from competing plugins.
- Does it look like one-man code? (Ambiguous labelling and sloppy structure only one person understands?) Or does it look super professional? (Easy for a whole team to keep track of.)
It’s a bit like building a house. If you know how to lay 2×4 and drywall, hammer and nails, you can definitely recognize the work of a superior carpenter…such as in a commercial building.
There’s a difference in level of class and scale that you can see. An enterprise-grade level dev organizes the code with its totality in mind. Every directory and file-name was thought out. Every place has a focus, has a function. You can just glance at the folder structure and already you can guess. Where things are and what they do. It even has comments everywhere telling you what it is and what it does.
Whereas a lower-level developer is obvious, because their code looks like…hmmm, what is this….oh it’s an engine…added to a wheel, added metal, added chairs, added windows…becomes a car! AHHHH….you realize what the heck it is only after carefully looking at the entire thing. (In real world scenarios, you might have dig through a maze of 20 php files and hundreds of lines of code before you understand where things are.)
12. Contractor pricing
This is a complex subject for those unable to read a developer’s thoughts. And should probably be a separate guide in itself. But I’ll touch on a few basic points here.
Developer pricing isn’t like usual product pricing…where MORE typically means BETTER. A developers pricing is a reflection of probably 2 or 3 things:
- their skill or experience
- their availability
- how much they want the job
Ideally, you get a great price with a skilled developer because they’re totally available and really want your job (because it’s fun, easy for them, they already built something similar). The worst case scenario is a low skill developer who’s too busy AND up-charges you because they plan to outsource it to another developer (who might also be too busy or not like your project).
You can check their skill easily using the methods above. Availability is hard to gauge as some developers like to take on new projects even when they’re totally swamped. But eagerness for taking the job is absolutely key. Among equally-skilled developers, their enjoyment of the task easily differentiates the quality of work.
How do you sense eagerness? A developer who really wants it will probably talk a lot explaining how they’d build certain parts, and in what order and ask great questions beforehand. They might even share similar projects they’ve done in the past and able to draw on past experience. But then again…how do you know it’s not just a desperate low-grade dev firm?
A developer who isn’t keen on the task except for the money will likely not want to talk much unless you put down a deposit. And try to schedule you for a date far away. And then again…how do you know this isn’t just a super professional staying more focused on existing clients than prospects?
It’s hard to tell if you’re new to this.
Good developers go the extra mile
They know what you’re trying to do.
And while they’re already in there, they figure to throw in some extras or do some extra cleaning on non-related issues. Or they might stop and challenge your idea to re-vision in a better way. They don’t just take your money and render what you ask verbatim. They share their experience in having built similar sites or working with similar clients.
Leave a Reply